> No one is going to write code in their own native language and > distribute it worldwide. > > How can you say that "PHP6 Unicode support is not designed for > international environment"? Have you even tried it?
Ok. International environment. Do you have strtoupper|strtolower|strcasecmp functions operating in LC_CTYPE=C without switching locale? If I remember correctly, PHP does not use those even internally and developers are constantly triggering same Turkish|Kurdish|Azerbaijani bug in different functions. If I want case conversion or case insensitive comparison functions to follow C rules and not LC_CTYPE=some_translation, I am forced to use own functions, because strtoupper|strtolower are definitely locale aware in PHP. PHP6 unicode.semantics=on reduces my options and forces me to recode all 8bit string operations. After recoding functions are not backwards compatible with anything lower than 5.2.1. Your slides show that unicode characters are defined with \u, yet you mess with octals (\300) and hexadecimals (\xC0). It is possible that I am not right and I will be able to do everything more efficiently in PHP6. But for now I have broken password encryption handling, broken work with binary strings and over noisy stream functions. And I still haven't checked how it will handle streams with data encoded in different character sets. I will be forced to recode the code if PHP6 forces me to work in unicode.semantics=on. Don't expect that I will praise PHP6 for that. You are helping same people, who ask others to turn on mbstring.func_overload in php.ini in order to get unicode support. You are not helping people who already have code working with 8bit strings in different character sets. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
