Re: What "Unicode support" really means

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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227