Re: why we must get rid of unicode.semantics switch ASAP

From: Date: Mon, 21 Jan 2008 19:56:15 +0000
Subject: Re: why we must get rid of unicode.semantics switch ASAP
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-34856@lists.php.net to get a copy of this message
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.

« previous php.internals (#34856) next »