Tomas Kuliavas schreef: ....
me, I'm all for dropping unicode.semantics - Antony makes strong points and it can only help the quality of the product if exceptions and switchable functionality is kept to a minimum. from a developers POV the same is true, additionally 'forcing' unicode on the masses will increase awareness and speed up the uptake of the necessary skills (imho). +1 for Antony's proposal
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
php6 is not even alpha stage yet AFAICT. lets give the devs a chance before jumping on these kinds of issues, no?
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.
same difference. I don't see how 'having' to maintain two incompatible versions for different [major] php versions is effectively any different to maintaining two incompatible versions due to the unicode.semantics switch. given past experience with attempts to offer users a compatibility switch (as Antony pointed out) it is very likely that the result will be that you'll actually end up maintaining 3 incompatible versions: php5, php6 US=on and php6 US=off. another point to consider is that more than likely the take up of php6 will not be very fast - comparable to php5's take up in the face of php4. given that this is likely to be the case you will probably have a long grace period where you'll only need to support php5 - time which can be spend developing towards php6 without the hassle of having to deal with production users, etc.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
