Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30194
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <4671F184.2020401@lerdorf.com>
Date: Fri, 15 Jun 2007 02:55:16 +0100
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Cristian Rodriguez <judas.iscariote@gmail.com>
CC:  internals@lists.php.net
References: <1181829227.3478.3.camel@localhost.localdomain> <7d5a202f0706141844l3c75b556hdbecbcd5a43747c9@mail.gmail.com>
In-Reply-To: <7d5a202f0706141844l3c75b556hdbecbcd5a43747c9@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6?
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Cristian Rodriguez wrote:
> On 6/14/07, Jani Taskinen <jani.taskinen@sci.fi> wrote:
> 
>> I mean, if PHP 6 is about unicode, why upgrade to PHP 6 and disable it?
> 
> I think if unicode.semantics remains PHP_INI_SYSTEM it is useless as
> most users ( people that runs in shared hosting servers) will simple
> not be able to turn it on, as well hosting companies will keep it off
> because turning it on will break applications.
> 
> So, either make it at least PHP_INI_PER_DIR or remove it all togeteher
> ( aka.. always behave like unicode.semantics= On)

Those same shared hosting companies would never upgrade to PHP 6 if we
forced unicode semantics on them breaking legacy apps and that would
force us to maintain PHP 5 forever.

We recognize that some people are simply not going to make the effort to
make their apps unicode aware anytime soon and that fact could easily
splinter the project across the unicode line.  If that unicode line
becomes synonymous with PHP 5 vs. PHP 6 we are in trouble.  I would much
rather have people on the same codebase so we can move everyone ahead on
other features and keep the unicode vs. non-unicode battle to a
configuration setting within that one codebase.  I really don't want to
get into the situation where we are backporting features to PHP 5 a
couple of years from now.

And we obviously did consider making it PER_DIR, but that is really
complicated.  The current cries that the unicode.semantics check is
complicating code are dull compared to what they would be if we allowed
a single process to switch back and forth potentially on the same scripts.

-Rasmus