Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6381
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <200312121823.54634.ilia@prohost.org>
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>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=SHIFT_JIS; format=flowed
Message-ID: <EE66B8E3-2CFE-11D8-9A2A-000A95CE0C62@at.wakwak.com>
Content-Transfer-Encoding: 7bit
Cc: PHP Internals <internals@lists.php.net>
Date: Sat, 13 Dec 2003 08:57:24 +0900
To: ilia@prohost.org
Subject: Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
From: moriyoshi@at.wakwak.com (Moriyoshi Koizumi)


On 2003/12/13, at 8:23, Ilia Alshanetsky wrote:

> 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().

What are you referring to as "a whole lot of different & unusual thing"?

> We have a multibyte extension for people who need
> that functionality, why force it on everyone else?

Because it's a bug. The multibyte extension we have is not provided
to make easier the lives of those who don't use multibyte encodings.

It exists as an extension since we had to do so in the past.

>>>> 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().

You should be underestimating the number of the people who *actually*
need it.

>
>> 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.

Escaping behaviour is totally irrelevant to the multibyte issue.
I think users should be able to choose by an optional argument
whether \" has to be treated as a escaped quote or a simple
sequence of a backslash and a quote.

Moriyoshi