>> During Derick's talk about PHP 6 at PHP Vikinger, I started to wonder >> what exactly was the reasoning behind adding something like >> "unicode.semantics" option. Derick didn't remember, neither did I. >> >> Apparently it's another one of these "register_globals" or >> "magic_quotes_*" directives we'll remove in PHP 7? :D >> >> I mean, if PHP 6 is about unicode, why upgrade to PHP 6 and disable it? >> Just stay with PHP 5 then.. > > Apparently there is a certain amount of users (undefined/undefinable > masses) who like to use PHP6 new features (?) without unicode. The > arguments were about the incompatibilities (the zend fatal errors are > likely to cause more troubles :) and performance. > > I was one who likes to have a single mode: unicode.
Changes made in PHP6 unicode_semantics=on are not backwards compatible with PHP4 and PHP5. Same scripts (for example, reading string in bytes) work in PHP4 and PHP5. They won't work in unicode_semantics=on. PHP6 places very strict checks on string variables. PHP script writers are not used to it. If developers have to maintain compatibility with PHP6 unicode_semantics=on, they will have to do that in separate code branch. PHP6 code will break with E_PARSE errors in older PHP installs. I don't like it, because I can't turn that thing off. Interpreter is trying to outsmart me without knowing my coding environment. If you need multibyte string support, you have mbstring extension. If you want unicode function and variable names, you should remember that they won't work in international coding environment. International developers must use something they all understand. It means ASCII and English function names. Will you understand purpose of the function, when function name is written in Russian, Chinese or Arabic? -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
