Re: What "Unicode support" really means

Stas Malyshev wrote:

Hi!

This is the underlying idea that I'm trying t cover by suggesting that 'English' is interpreted a little more flexibly and just allows names that do not cause problems with case insensitivity. HOWEVER I do think that there is a very strong

You can not do that. Saying "we support ASCII and another 247 characters" makes no sense - there's no way for users to ensure the DB uses only those 247 characters, and even if there were, enforcing it makes the whole thing unwieldy and useless.

In fact, you don't even have to venture outside plain old English to get into trouble. Take such common English word as "affliction". Now take such Unicode character as U+FB04, or "LATIN SMALL LIGATURE FFL". Now imagine we have two identifiers - "affliction" and "affliction" - because since we've declared "Unicode support for identifiers" in our PHP 6, you are using fully Unicode-supporting tool to write your code, and that tool uses ligatures to make your code look pretty. Now imagine to what lengths the engine has to go to support such thing? Properly supporting Unicode is hard.

So the road path for PHP6 should be that the bulk of variable/function names will only ever use ASCII-7 characters? Stopping those holes that currently allow some unicode strings to push through there currently? If the core code base is not going to support unicode - and I include unicode variables automatically created from XML and database data - then so be it. In which case there is nothing to fix as we just stick with mbstring to handle the data content of variables? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk