Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6383
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20031213011256.5a8g0sgw000kgwkw@neo.wg.de>
Date: Sat, 13 Dec 2003 01:12:56 +0100
To: internals@lists.php.net
References: <25BBBBC2-2CD2-11D8-8FCC-000A95CE0C62@at.wakwak.com>
	<200312121728.44466.ilia@prohost.org>
	<F9C15AC8-2CF3-11D8-9A2A-000A95CE0C62@at.wakwak.com>
	<200312121823.54634.ilia@prohost.org>
In-Reply-To: <200312121823.54634.ilia@prohost.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
Subject: Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable
	branch)
From: jan@horde.org (Jan Schneider)

Zitat von Ilia Alshanetsky <ilia@prohost.org>:

> 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().

Just a general note on this discussion becoming sort of a "meta"-topic:
From a PHP developers POV, complete charset support should be a key
technology for ZE and the standard extensions, as is now XML for PHP5 as a
whole. While the comparison might be a bit strange, it even reminds on the
relation of these two: The "standard" encoding for XML data is a multibyte
charset.

But the real problem is, that it's *really* hard for developers outside of
the "multibyte" world to understand the ins and outs of these charsets and
how to handle them correctly. It was a PITA to make the whole Horde
framework charset independent without knowing anything on mb charsets and
their support in php.
I did this due to popular demand, because there are a *lot* of people
using/needing mb charsets. It would be great if others developers wouldn't
have to take this steep road, because php would support these out of the
box.

While writing this message, Rasmus got my point in fewer words. ;-)

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft