Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain omegavortex.net from 207.210.105.50 cause and error)
Message-ID: <4794F8DF.5050304@omegavortex.net>
Date: Mon, 21 Jan 2008 13:56:15 -0600
Organization: Omega Vortex Corporation
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Tomas Kuliavas <tokul@users.sourceforge.net>
CC: internals@lists.php.net
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>
In-Reply-To: <37694.78.61.224.253.1200944299.nsm@avilys.eik.lt>
Content-Type: multipart/alternative;
 boundary="------------020801010401070406060205"
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
From: jeremy@omegavortex.net (Jeremy Privett)

--------------020801010401070406060205
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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-house
>>> apps are written for one specific PHP version and setup.
>>>       
>>   you're point being? Without the requested change here you would 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 broken. It
> replaces standard functions that worked same way through all PHP4-5
> versions and forces use of code that is totally backwards incompatible.
> 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 library or
> function.
>
> PHP introduced changes similar to unicode.semantics=on with mbstring
> function overloading. When I learned about it, I've stopped trusting ereg
> and string functions. With mbstring overloading I still have options to
> disable broken design. With unicode semantics I am forced to use features
> provided by interpreter instead doing things the way I want and having
> better controls over script.
>
> PHP with unicode.semantics on is more suitable for novice developers who
> are not familiar with character sets and lazy developers, who want their
> PHP4-5 code to become Unicode aware without any changes on their side. If
> PHP4-5 code works with multiple charsets and 8bit data, it will break in
> PHP6.
>
> I don't care if you remove this setting. I'll find the way to make my code
> work. but don't expect me to remain silent if you say that it is a good
> thing. It is good for PHP codebase. It is not good for portable PHP script
> developers. Removal of setting forces developers to drop 5.2.0 and older
> versions or to maintain two library versions. If setting remains,
> developers can ask to turn it off. PHP_INI_SYSTEM is php.ini and
> httpd.conf.
>
>   
And most people on shared servers don't have access to httpd.conf. As 
long as it's not PHP_INI_PERDIR, unicode.semantics will never be an 
acceptable solution. In my opinion, even if it were PERDIR, it still 
wouldn't be an acceptable solution as you'll still have portability 
problems, either way.

-- 
Jeremy Privett
C.E.O. & C.S.A.
Omega Vortex Corporation

Web:    http://www.omegavortex.net
E-Mail: jeremy@omegavortex.net

Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.


--------------020801010401070406060205--