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

From: Date: Mon, 21 Jan 2008 17:14:23 +0000
Subject: Re: why we must get rid of unicode.semantics switch ASAP
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-34850@lists.php.net to get a copy of this message
Hello Antony, +1 + thanks, it is simply a ppain in th eass to develop with 7) It alone is responsible for at least 10% slowdown. marcus Monday, January 21, 2008, 3:38:00 PM, you wrote: > 6 reasons why we must to get rid of The Switch ASAP > ---------------------------------------------------- > 1) it gives users false sense of "compatibility" when no compatibility is even > planned; > 2) it's supposed to mean compatibility, but can be changed only in php.ini, which > means users would still have to maintain 2 versions of their software: > one for On and second for Off. > 3) 2+ bigger codebase [1] (with lots of duplicates because we have to do > same things in native and unicode modes); > 4) increases the maintenance costs a lot [2]; > 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. > I believe most of the people here agree it was a total failure - untested, unneeded and, > most important, not working thing that complicates user's and developer's lives. > Those who want compatibility may and will stay with PHP5 forever, > those who need Unicode support will use PHP6. > 6) we need to remove the switch ASAP and make PHP6 Unicode-only before people spend > their time doing useless "compatibility ports" of their applications. > --- > [1] > > http://cvs.php.net/viewvc.cgi/php-src/ext/standard/string.c?revision=1.664&view=markup > Don't click this link if you want to sleep well today. > [2] Here is a typical problem: > http://bugs.php.net/bug.php?id=42861 > Try to fix it without looking at the solution and you'll see what I mean. > -- > Wbr, > Antony Dovgal Best regards, Marcus

« previous php.internals (#34850) next »