>> No problem. I just can't use it. It does not pass even basic "must >> work on >> Debian Stable" test. Option creates parsing errors in older PHP >> versions >> and I can't wrap it with PHP6 check. Such code must be stored in >> separate >> libraries loaded only in PHP6 and issue affects way to many functions. >> >> If scripts are portable, they should work on any PHP version without >> tweaks in PHP_INI_PERDIR configuration. Minimal 5.2.1+ requirement >> is not >> acceptable. We are not talking about code designed to work only on >> some >> selected setup. >> >> unicode.semantics is the third PHP configuration option that can >> seriously >> break things. First two are 'variables_order' and 'gpc_order'. > > Trust me, it was the only available solution we came up with that > balanced backwards compatibility and the new language semantics. > Would you rather that PHP 6 just updated language semantics without > giving you an option to turn certain behaviors off? > > IMHO, if you are set on working with binary strings exclusively, then > you should not turn unicode.semantics=on. Why are you trying to turn > it on if you are not using Unicode features?
I don't control PHP configuration used by end user. So I am trying to break scripts and make sure that scripts can handle misconfigurations gracefully. I have real world examples when other developers ask to turn on mbstring.func_overload in php.ini without any warnings that it might break other scripts. Some thing can happen to unicode.semantics. Best fix is to handle errors transparently without any intervention from end user. I can't do that with unicode.semantics. I have already said 'no problem'. I asked for better controls, you said that you can't do that. Fine, I'll use other way to handle broken setup. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
