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.