Derick Rethans wrote: > On Fri, 6 Jul 2007, Cristian Rodriguez wrote: > >> On 7/6/07, Johannes Schlüter <[EMAIL PROTECTED]> wrote: >>> which will just produce way more >>> problems to hosters and developers of software for "PHP 6". >> >> yes :-( .. So if unicode.semantics cannot be set at runtime with >> ini_set() or at least "per-dir" is a complete non-sense to have it, >> as the vast mayority of users will not be able to turn it On/off and >> will certainly be off in most configurations as otherwise it will >> break too much code. >> >> Im sorry but I dont see this ending as a good thing.. looks pretty >> much like more of the same old mistakes ( magic_quotes , safe_mode >> anyone ? this may be even worse..) > > This *is* worse because with magic_quotes you can atleast workaround it > in user land. Not so much with this setting.
It comes down to whether we want a true Unicode mode for PHP. As far as I am concerned, anything short of that is rather half-assed and feels bolted on like in other languages. The huge difficulty, and the reason it is bolted on after the fact in most languages, is that it is extremely difficult to transition from non-unicode to full unicode without breaking everything. The suggestion has been to just have a bunch of Unicode functions you can call so you explicitly control when you are doing Unicode stuff and the rest of the time you are working in binary mode. That's exactly what we have with the Unicode semantics turned off. The idea is for all the Unicode functionality to be available in this mode and like has been stated many times, this is the mode most ISP's are going to run their shared servers in and as such this is the mode a portable PHP script needs to be written for. However, does this mean we shouldn't even attempt to get it right? 5 years from now, are we still going to limp along having to call explicit functions to compare and iterate over unicode strings? Or heaven forbid, we end up with a mess of various string classes. A string is just a string, it isn't a class and it shouldn't be complicated. It should have carried a charset with it from day one, but it didn't, so we are where we are. So yes, the only real customers for this full Unicode mode in PHP 6 are going to be the folks that have full control over their servers and their software which will likely limit it to hosted services and exclude large PHP software packages that will necessarily need to be written to be portable. That of course creates a split right down the middle and makes code sharing harder, and maybe it won't work, but the hope is we can minimize these issues enough that the amount of code that realistically needs to be written twice will be rather limited. If we can't get it down to a manageable set of known things that people need to watch out for, then our full unicode attempt has failed and we need to stick with the half-assed approach. I'm not convinced we are there yet and I'd hate to see us give up before we have taken a decent stab at it. We need to think big and longterm, not small and shortterm here. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
