Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:6380 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11794 invoked by uid 1010); 12 Dec 2003 23:12:41 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 11770 invoked from network); 12 Dec 2003 23:12:40 -0000 Received: from unknown (HELO asuka.nerv) (24.112.18.98) by pb1.pair.com with SMTP; 12 Dec 2003 23:12:40 -0000 Received: (qmail 5904 invoked from network); 12 Dec 2003 18:07:50 -0000 Received: from rei.nerv (HELO dummy.com) (rei@192.168.1.1) by asuka.nerv with SMTP; 12 Dec 2003 18:07:50 -0000 Reply-To: ilia@prohost.org Organization: Prohost.org To: Moriyoshi Koizumi , PHP Internals Date: Fri, 12 Dec 2003 18:23:54 -0500 User-Agent: KMail/1.5.4 References: <25BBBBC2-2CD2-11D8-8FCC-000A95CE0C62@at.wakwak.com> <200312121728.44466.ilia@prohost.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200312121823.54634.ilia@prohost.org> Subject: Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch) From: ilia@prohost.org (Ilia Alshanetsky) On December 12, 2003 05:38 pm, Moriyoshi Koizumi wrote: > And I don't think fgetcsv() is an exception, since htmlentities() can > be referred to as an example that is placed in core and > supports multibyte strings. As I mentioned, purging that kind of > functionality into the mbstring extension doesn't solve the problem > in practice by any means. htmlentities() is a rather special function it handles not only multibyte but a whole lot of diffrent & unusual things. I do not think you can fairly compare it to fgetcsv(). We have a multibyte extension for people who need that functionality, why force it on everyone else? > >> 2) IMO speed is not a key factor here. People rather wants > >> trust-worthy behaviour. > > > > When it's a few percent and the changes offer significant improvements > > yes, > > but when were are talking about a performance loss of 250-300% or more > > then > > performance must become a consideration as well. > > If there are virtually no ways to improve it, it'd be natural to me > we dismiss the issue. Why does a vast majority of users have to endure degredation in performance for functionality that are needed by a few? It's as simple as that. Same argument applies to basename(). > One thing I'm talking about here is escaping behaviour, which I > mentioned in the previous mail. I believe it would be possible to implement in the 4.3.X code, however it sounds specific to multibyte implementation. Ilia