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/>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
