Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:6479 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 66497 invoked by uid 1010); 15 Dec 2003 23:24:00 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 66443 invoked from network); 15 Dec 2003 23:24:00 -0000 Received: from unknown (HELO imf21aec.mail.bellsouth.net) (205.152.59.69) by pb1.pair.com with SMTP; 15 Dec 2003 23:24:00 -0000 Received: from nutextonline.com ([208.60.234.91]) by imf21aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031215232356.CXWH22452.imf21aec.mail.bellsouth.net@nutextonline.com>; Mon, 15 Dec 2003 18:23:56 -0500 Message-ID: <3FDE5278.8020907@nutextonline.com> Date: Mon, 15 Dec 2003 18:31:52 -0600 User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Stig S. Bakken" , "[PHP-DEV]" References: <25BBBBC2-2CD2-11D8-8FCC-000A95CE0C62@at.wakwak.com> <200312131733.57805.ilia@prohost.org> <08B5D122-2DBF-11D8-B836-000A95CE0C62@at.wakwak.com> <200312131828.38053.ilia@prohost.org> <1071484672.1697.32.camel@kirin.dev.trd.p4pnet.net> In-Reply-To: <1071484672.1697.32.camel@kirin.dev.trd.p4pnet.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch) From: lateralus@nutextonline.com (Derek Ford) Stig S. Bakken wrote: >On Sun, 2003-12-14 at 00:28, Ilia Alshanetsky wrote: > > >>On December 13, 2003 05:52 pm, Moriyoshi Koizumi wrote: >> >> >>>I haven't denied it. That said, multibyte facility is not so fancy >>>as XML, but quite essential so as to enable most applications to work >>>well under every environment. >>> >>> >>Bullshit. Only application that need to support multibyte strings need the >>multibyte facility. >> >> >> >>>Let's stop doing such a stupid thing any more. As I pointed out already, >>>having different versions for each function doesn't solve problems at >>>all. >>> >>> >>It sure does, those who need to slower (multibyte) version use that and those >>who don't use the standard version which works nice and fast for >>non-multibyte strings. >> >> > >So you think the right solution is to dismiss multibyte users and direct >them to the hacks (mbstring etc) that have been used previously instead >of thinking ahead? > > I see no example of him implying he wanted to "dismiss" multibyte users, he simply suggested mb_* versions of the string manipulation functions and pointed available facilities that people can use already. I support that idea, as having a mb_ version and a version without multibyte support gives everyone what they want. People who want multibyte strings have it, and people who want speed without multibyte strings still have that; everyone should be happy. Those who don't need multibyte strings (the majority, by a long shot) don't have to suffer any performance loss, while those in Asia can open that marketshare you speak of. >If I were starting a language from scratch today, I would make character >encoding part of the string "zval" structure. IMHO that's where it >belongs. As an alternative for PHP 5[.1], there is room for a >"multibyte bit" in the zval that various functions can use to choose >between "sizeof(byte)==sizeof(char)" and "sizeof(byte) < sizeof(char)" >implementations. > > - Stig > > >