Send a blank email to [email protected] to get a copy of this message
I'm slowly working through a long list of things relating to unicode strings trying to work out just where the main problems are.
The very first problem I hit is ICU's limitation to 32bit string lengths. How does the switch to 64bit string length on 64 bit platforms impinge on this. While I can see the advantage of this particular change, would that also now require our own version of ICU capable of also handling longer strings? This probably falls out in the wash of my next point ...
Currently strings are simply strings? I'm sure we have already had this discussion, and it will be necessary to switch from simple strings to a string object which can handle the intricacies of unicode?
Pierre - I presume that it's this distinction that is where I'm crossing over between variable and similar names which just remain as simple stings while 'data' that is unicode is provided by sting objects. These then need to work nicely with areas that expect a simple string? Where a string object is returned an ASCII version will be created when a simple string is necessary?
The 'leak' of unicode currently into name strings is simply that there is nothing currently stopping them from storing UTF-8? That this works is more by luck than design, but results in subtle problems with case conversion and the like which does not expect unicode strings? BUT people can currently use any format data in a string even one using a 64 bit pointer as long as it does not go through a path that does expect ASCII?
If the simple string is isolated from UTF-8 and unicode is kept to it's own data type such as an improved integrated mbstring package then this make a suitable 'half way' house for PHP6?
I don't NEED unicode variable names, but I can see that this would be a nice to have in non-English speaking countries. In much the same way we provide translated versions of web pages, I can even see the advantage of function name aliases in different languages as having more relevance that simply changing the current English names for picky reasons, but that is not likely to happen in my lifetime! Perhaps PHP10 :)
--
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