On December 13, 2003 04:46 pm, Moriyoshi Koizumi wrote:
> > The critical point of this entire discussion is about NOT forcing
> > choices on
> > people who do not want/need them. There is no good reason to force
> > multibyte
> > version of fgetcsv() on every single user, when there are not one but
> > two PHP
> > extensions designed explicitly for multibyte support.
>
> On the other hand, the chances are very limited to users familiar
> to multibyte. First of all, flexibility on the configuration has been
> causing lots of confusion. I'd be happy if every existing application
> used mb_*() instead of their counterpart at approproate places, but
> it's unlikely. This is because we have two versions of string
> manipulation
> functions. And again, it's prevented users to write multibyte safe
> applications because multibyte-flavor extensions are currently not
> enabled
> by default though this fact is not my point.

Percentages aside you cannot deny the fact that not every application needs 
multibyte support (whether this is a majority or 50/50 does not matter). 
If a user needs to use multibyte they may need to do a little searching to 
find a provider that supports it, fortunately for them PHP is a very common 
scripting language with many hosting providers.

> > If fgetcsv() in PHP 5 cannot be designed in such a way as to have no
> > significant performance penalties for non-multibyte strings the
> > function
> > should be introduced as mb_fgetcsv() or iconv_fgetcsv().
>
> So, why not begin thinking of how it could be bearably fast
> even with multibyte support enabled? While I think the current stuff
> I made is the best portable and the fastest code, it's probable
> that there are a far better code.

If your code as indeed as fast as it can be then the only alternative it would 
seem is to seperate the function into 'normal' and 'multibyte' variants 
allowing the user and not the developer to choose the one most suited to 
their needs.

Ilia

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to