Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6386
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: ilia@prohost.org
To: Jan Schneider <jan@horde.org>,
 internals@lists.php.net
Date: Fri, 12 Dec 2003 19:47:01 -0500
User-Agent: KMail/1.5.4
References: <25BBBBC2-2CD2-11D8-8FCC-000A95CE0C62@at.wakwak.com> <200312121823.54634.ilia@prohost.org> <20031213011256.5a8g0sgw000kgwkw@neo.wg.de>
In-Reply-To: <20031213011256.5a8g0sgw000kgwkw@neo.wg.de>
Organization: Prohost.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200312121947.01721.ilia@prohost.org>
Subject: Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
From: ilia@prohost.org (Ilia Alshanetsky)

Before we get too far offtopic ( fgetcsv() ) let me just quickly summarize my 
position. I think it's great that multi-byte support exists in PHP, we have 
mbstring, iconv and recode extensions that all help make PHP work with 
multibyte strings.
As with most things with PHP the user has a choice of whether or not to enable 
this functionality depending on their present and future needs. By putting 
this functionality into core/standard this choice is taken away more over it 
penalizes (rather significantly) every single user of affected functionality. 
That is what I'd like to avoid.

Without mbstring enabled, you would not be able to effectively work with 
multibyte characters. Therefor even if fgetcsv() would work as you may expect 
with multibyte strings, that data would not be manageable in most cases. 
Which is why I propose that multibyte version of fgetcsv() be placed inside 
ext/mbstring as mb_fgetcsv().

Ilia