Re: What "Unicode support" really means

Hi! > Where projects are case sensitive the 'decision' to allow unicode variables was > less of a problem. They are just a little longer than conventional variables. It > is the very fact that case insensitivity is part of PHP that is making this Case is only one of the problems. Normalization and dealing with various edge cases is another. E.g. what to do when name if presented in different normalization forms? What "numeric" or "alphanumeric" means in unicode? Etc. etc. > difficult. Like you Stas I can get away with 'English' names, but the major > problem I am seeing is not so much Function names, but simply keys in arrays. If > one is working with current versions of databases that ARE using unicode for > field names, then the key names for associative arrays need to handle unicode! Not really. As long as you don't mess with what DB returns, there's nothing to "handle". How often you need to transform the column name from the DB (beyond maybe simple concatenation to make foo.bar or foo.bar)? Practically never. However, DB returns are data, not identifiers. There's some confusion between them (i.e., some API may use $foo->bar to access column "bar") but this can be resolved by always providing data APIs that do not require full unicode in identifiers. > 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227