Re: why we must get rid of unicode.semantics switch ASAP

On 21 Jan 2008, at 19:38, Tomas Kuliavas wrote:

5) this is yet another reincarnation of ze1_compatibility switch.

Which is the worst mistake ever imo - If you wanted PHP 4 you would simply use PHP 4. Now if you want PHP 5 just damn use PHP 5.

And if you don't control PHP version used by end user? Only bad in-house apps are written for one specific PHP version and setup.

you're point being? Without the requested change here you would have one more version, resulting in PHP 5.*, PHP 6.*-unicode, PHP6.*-native.

there is only a little difference between php5 and php6 with unicode.semantics off. php6 with unicode.semantics on design is broken. It replaces standard functions that worked same way through all PHP4-5 versions and forces use of code that is totally backwards incompatible.

I wholly agree that this is idiotic — I'd much rather see an approach to Unicode strings like there is in Python, namely that any string is binary data unless explicitly prefixed by u (e.g., gettype('a') == 'binary' && gettype(u'a') == 'unicode'). We already have support for similar syntax in the form of b'…'. This alternative, unlike the current situation, allows code written for PHP < 6 to run on PHP 6 without issue.

binary and unicode typecasting triggers E_PARSE errors in older PHP versions. I can't mix PHP6 and older PHP code in one script or library or function.

(binary) is fine on PHP 5.2.1 and above, though it's still a far from ideal situation (as it relies on unicode.runtime_encoding unlike b'…'). It is most certainly possible to get code working on both PHP 5 and PHP 6, but it requires a lot of verbose code (that can, on the upside, all be abstracted into unicode/binary classes that each deal with a different string type (which also gives an excuse for a PHP 5 userland implementation of unicode, so you can rely on unicode support on both PHP 5 and PHP 6)).

PHP introduced changes similar to unicode.semantics=on with mbstring function overloading. When I learned about it, I've stopped trusting ereg and string functions. With mbstring overloading I still have options to disable broken design. With unicode semantics I am forced to use features provided by interpreter instead doing things the way I want and having better controls over script.

I already refuse to support mbstring.func_overload as there is absolutely no way to get back to dealing with binary strings. If PHP 6 continues on how it is I may well end up not supporting it either. If PHP 6 breaks backwards compatibility I'd rather it did so far more sweepingly, without options to give the allusion of it being compatible with previous versions. -- Geoffrey Sneddon <http://gsnedders.com/>