Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25550
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.206 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=WeketzjY4DwyX6UO7WjUuNkN/HLUobsFaDza+K7fKeH0+8bYsKfmqNM4viAiPACfr5ZN2Ux0WlLfn/RY/YrmcZwRisV55KhkwsOlGKJ2rP6ovLkqc8eJnBbGqOU2ypyB3VSpcgQ2IGyhn5z5wrb09CwpAjpq1T0l1bbb3ssYibI=
In-Reply-To: <44FF1336.1070007@php.net>
References: <2b9a524b62303d2b7c3f5e20a7b86537@gravitonic.com> <F005768A-1424-49D0-A3AA-B33F8330309D@prohost.org> <44FF1336.1070007@php.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <2222C69E-0E9B-4C76-9696-179E3E570FB8@prohost.org>
Cc: Andrei Zmievski <andrei@gravitonic.com>,
 PHP Internals <internals@lists.php.net>,
 Dmitry Stogov <dmitry@zend.com>
Content-Transfer-Encoding: 7bit
Date: Wed, 6 Sep 2006 14:47:27 -0400
To: M. Sokolewicz <tularis@php.net>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] RFC: unicode.semantics: runtime or not?
From: ilia@prohost.org (Ilia Alshanetsky)


On 6-Sep-06, at 2:28 PM, M. Sokolewicz wrote:

> 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?

Well, with unicode semantics enabled, many PHP applications that have  
not been designed with PHP6+unicode in mind are likely to break. On  
the other hand when semantics are off, those applications may work  
just fine. The other reason could be that unicode enabled PHP will be  
noticeably slower then the one without it, so hosters to conserve  
system resources may only enable it for people who actually need the  
functionality.

Ilia Alshanetsky