On Tue, July 10, 2007 7:06 pm, Larry Garfield wrote: > If 90% of the strings in use would work fine if treated as unicode, > then it > would make sense to just always assume Unicode unless explicitly > specified > otherwise.
If that 10% includes enough users who have written millions of line of code in a self-consistent manner that voids ALL their work, you may want to re-think this 90% number you have chosen... And of course you need 2 distinct data types for Unicode and strings. What I don't understand is why you'd lock things down so that: a) the default "string" is Unicode, breaking XX% of existing applications b) the end user can't readily change a) in a huge percentage of existing install base (read: non-dedicated hosting or mixed-user servers with shared httpd.conf settings) I realize it's far too late by now to do anything about it, most likely, but why in the world didn't you just choose a new keyword to define/declare a string as Unicode? And did I dream the thread on this way back when where it was stated that Unicode was backwards-compatible, so this wouldn't be a problem? Yet now it seems that UTF-16 is *not* backwards-compatible, and this seems like a pretty big problem to me. Oh well. I guess I'll just shut up and hope most of my code doesn't break when I go copying/pasting it into new sites that are locked into Unicode mode with no way for me to change that... -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
