Cristian Rodriguez wrote: > On 6/14/07, Jani Taskinen <[EMAIL PROTECTED]> wrote: > >> I mean, if PHP 6 is about unicode, why upgrade to PHP 6 and disable it? > > I think if unicode.semantics remains PHP_INI_SYSTEM it is useless as > most users ( people that runs in shared hosting servers) will simple > not be able to turn it on, as well hosting companies will keep it off > because turning it on will break applications. > > So, either make it at least PHP_INI_PER_DIR or remove it all togeteher > ( aka.. always behave like unicode.semantics= On)
Those same shared hosting companies would never upgrade to PHP 6 if we forced unicode semantics on them breaking legacy apps and that would force us to maintain PHP 5 forever. We recognize that some people are simply not going to make the effort to make their apps unicode aware anytime soon and that fact could easily splinter the project across the unicode line. If that unicode line becomes synonymous with PHP 5 vs. PHP 6 we are in trouble. I would much rather have people on the same codebase so we can move everyone ahead on other features and keep the unicode vs. non-unicode battle to a configuration setting within that one codebase. I really don't want to get into the situation where we are backporting features to PHP 5 a couple of years from now. And we obviously did consider making it PER_DIR, but that is really complicated. The current cries that the unicode.semantics check is complicating code are dull compared to what they would be if we allowed a single process to switch back and forth potentially on the same scripts. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
