Stig S. Bakken wrote:
On Sun, 2003-12-14 at 00:28, Ilia Alshanetsky wrote:
On December 13, 2003 05:52 pm, Moriyoshi Koizumi wrote:
I haven't denied it. That said, multibyte facility is not so fancy
as XML, but quite essential so as to enable most applications to work
well under every environment.
Bullshit. Only application that need to support multibyte strings need the
multibyte facility.
Let's stop doing such a stupid thing any more. As I pointed out already,
having different versions for each function doesn't solve problems at
all.
It sure does, those who need to slower (multibyte) version use that and those
who don't use the standard version which works nice and fast for
non-multibyte strings.
So you think the right solution is to dismiss multibyte users and direct
them to the hacks (mbstring etc) that have been used previously instead
of thinking ahead?
I see no example of him implying he wanted to "dismiss" multibyte users,
he simply suggested mb_* versions of the string manipulation functions
and pointed available facilities that people can use already. I support
that idea, as having a mb_ version and a version without multibyte
support gives everyone what they want. People who want multibyte strings
have it, and people who want speed without multibyte strings still have
that; everyone should be happy. Those who don't need multibyte strings
(the majority, by a long shot) don't have to suffer any performance
loss, while those in Asia can open that marketshare you speak of.
If I were starting a language from scratch today, I would make character
encoding part of the string "zval" structure. IMHO that's where it
belongs. As an alternative for PHP 5[.1], there is room for a
"multibyte bit" in the zval that various functions can use to choose
between "sizeof(byte)==sizeof(char)" and "sizeof(byte) < sizeof(char)"
implementations.
- Stig
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
