Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6462
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: ilia@prohost.org
Cc: Moriyoshi Koizumi <moriyoshi@at.wakwak.com>,
   PHP Internals <internals@lists.php.net>
In-Reply-To: <200312121728.44466.ilia@prohost.org>
References: <25BBBBC2-2CD2-11D8-8FCC-000A95CE0C62@at.wakwak.com>
	 <200312121551.25399.ilia@prohost.org>
	 <C7B74660-2CE8-11D8-9A2A-000A95CE0C62@at.wakwak.com>
	 <200312121728.44466.ilia@prohost.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: Overture Services Norway
Message-ID: <1071483496.1700.22.camel@kirin.dev.trd.p4pnet.net>
Mime-Version: 1.0
Date: Mon, 15 Dec 2003 11:18:16 +0100
Subject: Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable
	branch)
From: Stig.Bakken@overture.com ("Stig S. Bakken")

On Fri, 2003-12-12 at 23:28, Ilia Alshanetsky wrote:
> On December 12, 2003 04:18 pm, Moriyoshi Koizumi wrote:
> > I disagree, because of the following reasons:
> >
> > 1) Not a few people *actually* use fgetcsv() commonly
> >     with multibyte characters indeed. Regarding this,
> >     applications made by those who don't use
> >     such characters don't (and won't) use multibyte specific
> >     functions and that's the problem. This greatly prevents
> >     them from being portable.
> 
> People have lived without multibyte support in fgetcsv() for many years now, 
> and I did not see a single request on bugs.php.net for fgetcsv() multi-byte 
> support. So, while this is certainly useful functionality I do not believe it 
> is as widely needed as you say it is. We also have a multibyte extension that 
> already implements multi-byte safe variants of common functions, why make 
> exception for fgetcsv() and add multibyte code into core?

Just an observation: it seems that the PHP users who need multibyte
support are generally self-supplied by default.  It's often hard to
convince programmers to change their code as fundamentally as you often
need to do to support not just UTF-8 but the whole range of CJK
charsets, it adds complexity and can slow things down.  These users are
used to maintaining their own patches for all kinds of software.  The
process of merging in multibyte character features often takes several
years.

Because of this (if my observation is correct), you can't really tell
for example how many Japanese users are having issues with fgetcsv() by
counting requests on bugs.php.net.

I agree with Moriyoshi Koizumi that performance is not necessarily the
primary factor here.  IMHO performance is important, but generality and
realibility is more so.

With all due respect to everyone, I think that we should be a bit more
welcoming to people who offer help in making PHP a better language for
CJK websites.  There's still a huge amount of marketshare waiting for
PHP in Asia. :-)

 - Stig