Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34857
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.128.190 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=from:to:in-reply-to:subject:x-priority:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer;
        b=PM0WVnviMleFw1wPwFKKP2Iq4t/zDytAxQ7kLIhDDa0M748Bbu1/fGfbEXQkNyLjBsYVHf7FCcxkfHtSGb8TI1YbENA94clLB+tjl6W++L++JTBVDTa3reWC2vH2CWXrm7hIK3VD4YQMP+hrV5sRKvjEhn7ltUbrZNf9vszIQF8=
To: Tomas Kuliavas <tokul@users.sourceforge.net>
In-Reply-To: <37694.78.61.224.253.1200944299.nsm@avilys.eik.lt>
References: <4794AE48.20005@daylessday.org> <676382454.20080121181423@marcus-boerger.de> <45032.78.61.224.253.1200936152.nsm@avilys.eik.lt> <9810532581.20080121195543@marcus-boerger.de> <37694.78.61.224.253.1200944299.nsm@avilys.eik.lt>
Message-ID: <7AC1F748-FFA8-4993-9CF4-352F395679D2@googlemail.com>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v915)
Date: Mon, 21 Jan 2008 21:01:37 +0000
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
From: foolistbar@googlemail.com (Geoffrey Sneddon)


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-=20=

>>> house
>>> apps are written for one specific PHP version and setup.
>>
>>  you're point being? Without the requested change here you would =20
>> 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 =20
> broken. It
> replaces standard functions that worked same way through all PHP4-5
> versions and forces use of code that is totally backwards =20
> incompatible.

I wholly agree that this is idiotic =97 I'd much rather see an approach =20=

to Unicode strings like there is in Python, namely that any string is =20=

binary data unless explicitly prefixed by u (e.g., gettype('a') =3D=3D =20=

'binary' && gettype(u'a') =3D=3D 'unicode'). We already have support for =
=20
similar syntax in the form of b'=85'. This alternative, unlike the =20
current situation, allows code written for PHP < 6 to run on PHP 6 =20
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 =20
> library or
> function.

(binary) is fine on PHP 5.2.1 and above, though it's still a far from =20=

ideal situation (as it relies on unicode.runtime_encoding unlike =20
b'=85'). It is most certainly possible to get code working on both PHP 5 =
=20
and PHP 6, but it requires a lot of verbose code (that can, on the =20
upside, all be abstracted into unicode/binary classes that each deal =20
with a different string type (which also gives an excuse for a PHP 5 =20
userland implementation of unicode, so you can rely on unicode support =20=

on both PHP 5 and PHP 6)).

> PHP introduced changes similar to unicode.semantics=3Don with mbstring
> function overloading. When I learned about it, I've stopped trusting =20=

> ereg
> and string functions. With mbstring overloading I still have options =20=

> to
> disable broken design. With unicode semantics I am forced to use =20
> 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 =20
absolutely no way to get back to dealing with binary strings. If PHP 6 =20=

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 =20=

sweepingly, without options to give the allusion of it being =20
compatible with previous versions.


--
Geoffrey Sneddon
<http://gsnedders.com/>