Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30262
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain users.sourceforge.net from 213.197.162.99 cause and error)
Message-ID: <49348.78.61.224.253.1182270469.squirrel@avilys.eik.lt>
In-Reply-To: <4677F3FA.3010000@pooteeweet.org>
References: <1181829227.3478.3.camel@localhost.localdomain>
    <7d5a202f0706141844l3c75b556hdbecbcd5a43747c9@mail.gmail.com>
    <4671F184.2020401@lerdorf.com>
    <6sof73dj69ldpspfc5ukrc58qr9ckbin2b@4ax.com>
    <4677E7B1.2080305@lerdorf.com>
    <fe05d1540706190808o1d9305b3td74edd6d1c75c97@mail.gmail.com>
    <4677F3FA.3010000@pooteeweet.org>
Date: Tue, 19 Jun 2007 19:27:49 +0300 (EEST)
To: internals@lists.php.net
User-Agent: NaSMail/1.0
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6?
From: tokul@users.sourceforge.net ("Tomas Kuliavas")

> Pierre wrote:
>> On 6/19/07, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
>>
>>> But this is no different from writing code that will work on both PHP 5
>>> and PHP 6.  The only difference is that instead of checking for PHP 5
>>> you will be checking for Unicode.  Like I said, we don't want the
>>> Unicode decision to be synonymous with PHP 5 vs. PHP 6 because then the
>>> non-Unicode folks will never get the benefits of the non-Unicode
>>> improvements in PHP 6 and we would be forced to support PHP 5 for a lot
>>> longer.  We really stretch our already thing resources in order to
>>> support multiple branches, so anything we can do to get as many people
>>> as possible onto the same codebase helps us a lot.
>>
>> Just as a last (hopefully) comment, even if nothing seemed to have an
>> influence, no matter how many we are to prefer a unicode only mode (so
>> far only you are in favour of it, maybe Andree too but I don't
>> remember his opinion on this topic :).
>>
>> The gain we hope to have by keeping a non unicode mode is about having
>> more users moving to PHP6. I would like to know why it will work
>> better than with php5, any thoughts?
>>
>> And let forget that maintaining (and develop/implement) these two
>> modes will obviously take more time.
>
> I agree, we tried out best in PHP5 to provide support for PHP4 and it
> seems this has not been overly successful. Why will this be any easier
> for PHP6? Maybe we should try a different approach. Lets not hold
> ourselves back. Lets break BC where it makes sense. Projects like PEAR
> etc. could always claim that its also PHP5 compatible without truly
> moving over. If we make a clean cut, this will not work anymore and
> instead we have an opportunity to clean up, improve performance a bit by
> removing unicode off hacks and let users migrate or stay. Sooner or
> later they will be attracted by new shiny stuff and then they will make
> a true effort to migrate over instead of these half migrations that
> happened with PHP5 "adoption".

Nope. If I can't turn off unicode_semantics, I will ask end users to use
PHP5 or write manual about running two PHP versions on one host. I can't
update code to work on PHP6 unicode_semantics=on, because it affects lots
of functions and updates will break backwards compatibility with PHP4 and
some PHP5 versions. I suspect that I won't be able to set stream encoding,
because I will have to read the stream in order to know encoding of 8bit
data. In some cases data is provided by third party and character set
information can be incorrect. In some cases same stream can output data in
different character sets. In some cases automatic charset conversions
performed by PHP libraries might break verification of received data.

I won't be attracted with new shiny stuff. Last shiny stuff that I can use
is available in PHP 5.1.0.

I don't care about Unicode support, because it breaks things. I suspect
that PHP6 Unicode extension won't give me controls that I have in PHP5 and
PHP4 strings. PHP6 Unicode support is not designed for international
environment. It is designed for nationalized environments and allows PHP
script developers to code in their native language. Code written in
French, Russian, Arabic, Japanese or Chinese is not international. Only
some people can read it. Only some people can see difference between ァ()
and ィ(). If I have to debug code written in Japanese or Arabic, language
is the main barrier in understanding the code.

-- 
Tomas