Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25548
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 195.121.247.11 cause and error)
Date: Wed, 06 Sep 2006 20:28:06 +0200
In-reply-to: <F005768A-1424-49D0-A3AA-B33F8330309D@prohost.org>
To: Ilia Alshanetsky <ilia@prohost.org>
Cc: Andrei Zmievski <andrei@gravitonic.com>,
 PHP Internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Message-ID: <44FF1336.1070007@php.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13)
 Gecko/20060414
References: <2b9a524b62303d2b7c3f5e20a7b86537@gravitonic.com>
 <F005768A-1424-49D0-A3AA-B33F8330309D@prohost.org>
Subject: Re: [PHP-DEV] RFC: unicode.semantics: runtime or not?
From: tularis@php.net ("M. Sokolewicz")

Ilia Alshanetsky wrote:

>  From a technical perspective it makes sense to keep it php.ini only  
> setting or as Sara insists (STARTUP phase only). However, from a user  
> (hosting companies) perspective it adds a fair degree of complexity  to 
> their setup, which would probably mean one php6 instance will need  to 
> run as CGI or FCGI, which will without a doubt affect adoption  rates 
> and/or or unicode.semantics being enabled by default on most  installs.
> 
> Personally, I think we'd be better off with a slower adoption rate,  but 
> a more robust PHP without added engine/language complexity per- dir 
> unicode.semantics would add.
> 
> Ilia Alshanetsky

My personal opinion, as humble as it may be, is that it's pure bullshit 
to even give the chance of disabling it. WHY in hell's name would you 
want to give hoster's the choice? I can see a part of the hosts 
disabling it to "give an easy transition" while another part of the 
hosts enable it to "give the new features a chance". If Unicode support 
it supposed to be such a big part of the while PHP6 release then why do 
you give the option of disabling it? you're breaking away part of the 
MAIN reason why people would want to upgrade in the first place.

Just imagine what a mess it would be if you had given the choice of 
"disabling" the OOP support in PHP5. Be very very very glag you didn't 
do that, and as such I'd suggest not doing something equally drastic in 
PHP6.

Anyway, just a user's point of view here.

Maciej Sokolewicz