>>>>> 3) 2+ bigger codebase [1] (with lots of duplicates because we have to >>>>> do >>>>> same things in native and unicode modes); >>>>> >>>> From the cross-reference I assume you mean PHP's codebase. We still >>>> need binary string support — Unicode is only suitable for textual >>>> content. Images, for example, are binary data and we still need binary >>>> strings for them. Not everything people deal with in PHP is a textual >>>> string. >>>> >>>> >>> He could really be referring to both, honestly. The size of codebases >>> in >>> PHP applications will grow as a result, as developers will have to >>> provide the "compatibility ports" for making their code work with both >>> the switch on and off. Either that, or they just have to support one or >>> the other, but not both. Which results in vendors alienating their >>> userbase because they happen to be on a host or server that has the >>> option set out of their favor for whatever reason. >>> >>> And if I remember correctly, there's an explicit typecast (binary) for >>> binary data now, isn't there? >>> >> >> unicode and binary typecasts are not backwards compatible. >> >> > I think the emphasis on the PHP6 release needs to be taken off the > backwards compatibility and placed more on fixing what's broken about > the current solution. If people need Unicode to the point that they're > willing to make the jump to PHP6, then they'll do just that. It's > terribly inefficient to try and make everything easy on everyone and > your end result is hurting the internals developers for the sheer amount > of headache that's being caused by the current implementation. You can't > have it all, so instead of trying to make PHP6 backwards compatible, how > about the focus be placed on making it BETTER than PHP5?
over noisy standard string functions that require strict unicode/binary type checks - worse than php5 locale functions that report success even when locale is invalid - worse than php5 can't use same code in php5 and php6 - bad. Instead of making your code backwards compatible, you are forcing others to maintain two incompatible codebases. unicode.semantics is not php.ini only, it is PHP_INI_SYSTEM. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
