Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:6480 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86242 invoked by uid 1010); 15 Dec 2003 23:36:53 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 86196 invoked from network); 15 Dec 2003 23:36:52 -0000 Received: from unknown (HELO colo.lerdorf.com) (66.198.51.121) by pb1.pair.com with SMTP; 15 Dec 2003 23:36:52 -0000 Received: from rasmus2.corp.yahoo.com (rasmus2.corp.yahoo.com [207.126.232.175]) by colo.lerdorf.com (8.12.10/8.12.10/Debian-5) with ESMTP id hBFNaov8031898; Mon, 15 Dec 2003 15:36:50 -0800 Date: Mon, 15 Dec 2003 15:36:45 -0800 (PST) X-X-Sender: rasmus@thinkpad.lerdorf.com To: Derek Ford cc: "Stig S. Bakken" , "[PHP-DEV]" In-Reply-To: <3FDE5278.8020907@nutextonline.com> Message-ID: 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> <3FDE5278.8020907@nutextonline.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on colo Subject: Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch) From: rasmus@php.net (Rasmus Lerdorf) On Mon, 15 Dec 2003, Derek Ford wrote: > 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. It is a dismissal in the sense that existing apps not written explicitly for multibyte support will not work for nearly half the users of PHP. We are not talking about a small group of users here. As Stig says, the correct solution would be to always store the encoding of the string right alongside the length of the string in the guts of PHP. Anything short of that is going to be a hack. PHP6 here we come... -Rasmus