Re: What "Unicode support" really means

Lester Caine wrote:

Rowan Collins wrote:

Lester Caine wrote (on 06/03/2014):

One of the proposals has been to retain ASCII for all of the 'program' related strings, and this was just a proposal for a 'half way house' solution where the processing is UTF-8, but we work internally with a 'locale' that only worries about case insensitivity for the 'single byte' subset of characters? [...] See other post ... The PROGRAM side of string operations allow case insensitive function and variable names which gets totally screwed if a case conversion also changes the string length! Handling unicode data IN variables is a no brainer. It's using unicode strings to describe the variable that is the sticking point.

Ah, OK, I'd only been considering Unicode *values* here. I would tend to think of Unicode *identifiers* as a completely separate issue. There are already plenty of things that are valid strings but not valid identifiers, so I imagine that would be a subset, based on code point categories or some such.

As Pierre has identified, it's chicken and egg. With the right library many problems may well go away, but which is the right library will depend on just which problem we are trying to fix? ICU lays down a few rules which may not be the best path for PHP, so using something else in addition does make sense. It will have to be tailored for PHP anyway ... work with ICU for the grunt work ... and probably done not currently exist :(

DOES not currently exist ... -- 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