On 2003/12/14, at 6:19, Ilia Alshanetsky wrote:

On December 13, 2003 03:53 pm, Moriyoshi Koizumi wrote:
Could a quarter be a minority?

Unless the rules of mathematics had changed 25% is still a minority. You also
forget that there are plenty of people who compile extensions and never end
up using them.

A similar fact applies to your assumption. It's also true that PHP can
handle multibyte strings without mbstring or iconv in some cases where
the users are just fortunate enough to not get in trouble, most likely
because they just don't use such multibyte characters that are known
to cause problems due to its structure. Those user question [1][2] exactly
describes when it goes wrong.


[1] http://marc.theaimsgroup.com/?l=php-dev&m=103828989330521&w=2
[2] http://news.php.net/article.php?group=php.i18n&article=633

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.


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.

Moriyoshi





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



Reply via email to