Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:45162 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45382 invoked from network); 31 Jul 2009 08:25:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Jul 2009 08:25:10 -0000 Authentication-Results: pb1.pair.com header.from=mozo@mozo.jp; sender-id=permerror Authentication-Results: pb1.pair.com smtp.mail=mozo@mozo.jp; spf=permerror; sender-id=permerror Received-SPF: error (pb1.pair.com: domain mozo.jp from 209.85.211.201 cause and error) X-PHP-List-Original-Sender: mozo@mozo.jp X-Host-Fingerprint: 209.85.211.201 mail-yw0-f201.google.com Received: from [209.85.211.201] ([209.85.211.201:34187] helo=mail-yw0-f201.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 22/B3-26675-46AA27A4 for ; Fri, 31 Jul 2009 04:25:09 -0400 Received: by ywh39 with SMTP id 39so1473915ywh.16 for ; Fri, 31 Jul 2009 01:25:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.67.20 with SMTP id p20mr1725592aga.5.1249028706126; Fri, 31 Jul 2009 01:25:06 -0700 (PDT) In-Reply-To: <4A71DA47.8080809@zend.com> References: <4A6C6496.7060603@mozo.jp> <4A71DA47.8080809@zend.com> Date: Fri, 31 Jul 2009 17:24:46 +0900 Message-ID: To: Stanislav Malyshev Cc: php-dev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU From: mozo@mozo.jp (Moriyoshi Koizumi) On Fri, Jul 31, 2009 at 2:37 AM, Stanislav Malyshev wrote: > Hi! > >> Aren't there any interests on this? If you think PHP 6 is gonna cover >> all of the functionality that allegedly-cruft mbstring currently >> provides, that is almost wrong :-p > > Could you please explain why PHP6 doesn't provide what mbstring is doing? > I.e, let's go over the functions: > > mb_parse_str - since detecting encoding doesn't work per RFC, what is the > usefulness of this function? Wouldn't PHP 6 do the same with correct > charset? As for this you got the point. > mb_str* - shouldn't you in 6 just convert them to unicode and do all string > operations with Unicode strings? Also, in 5 isn't there some intersection > with grapheme_* functions? mb_strwidth() and mb_strimwidth() are not covered. > mb_output_handler - shouldn't setting the proper encoding in 6 do the same job? > mb_convert_encoding - don't we already have a number of functions that do encoding conversions? I don't think It can gracefully handle characters that have no corresponding entries in the target character set. I'm even thinking of adding a class interface that is dedicated to encoding conversion with which one can deal with such characters in a user-supplied handler. Regards, Moriyoshi