> If we don't make the functions provide reasonable behavior for
unicode, then every program needs to be rewritten to change function names.
I agree. I asked it because the Backwards Compatibility section states
the following:
"... the upgrade to Unicode-enabled PHP has to be transparent. This
means that the existing data types and functions must work as they have
always done."
For those functions written for single byte encoding, the upgrade to
Unicode-enabled PHP will be transparent because the character semantics
remains same. For those functions written for multi byte encoding using
mb_str*() functions, it will be also transparent.
It is okay if there is no way to save those functions written for multi
byte encoding abusing the str*() functions.
Makoto
Tex Texin wrote:
1) sorry I am compelled to change the subject so all threads don’t look the
same.
2) It's a no-win situation. If we don't make the functions provide reasonable
behavior for unicode, then every program needs to be rewritten to change
function names.
The number of places where hard coded constants (6) are used is probably much
smaller.
At least this way most code does the right thing as-is.
Also, if you don't want functions to show unicode behavior, leave unicode off,
and just convert the data to utf-8.
We do need to have functions that provide the raw byte length, so it will be
available.
Tex Texin
Internationalization Architect, Yahoo! Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
