Re: What "Unicode support" really means

On 10 Mar 2014, at 12:24, Lester Caine <lester@lsces.co.uk> wrote: > Pierre Joye wrote: >> On Mon, Mar 10, 2014 at 7:52 AM, Lester Caine <lester@lsces.co.uk> wrote: >> >>> Until there is some agreement here I don't think that the next stage can be taken >>> forward. >> >> I disagree here. Unicode support for identifiers (see below) is a very >> small part of what is required to actually support Unicode. See my >> initial mail about Unicode support, I think it would help to focus on >> the design first, before going down (or better said, up) to the user >> land details. >> >>> If the core is ASCII only, then PHP requires other solutions to handling >>> unicode material in databases ... that needs to be part of the roadmap. >>> >>> I will quite happily accept ASCII only core, but IS it the right way >>> forward? Or just another quick fix to something people see as too difficult? >> >> The core won't support ascii only, that's the whole point. But I only >> referred to Unicode names for identifiers (variables, contants, >> methods, classes or functions names). > > I'm sure that this is just a matter of translation here ... > Perhaps I am simply using the wrong words? > > The 'core' that I am talking about IS simply variables, constants, methods, classes > or functions names ... the metadata required to write a program? The use of unicode rather than > ASCII strings to define those variables should not be a problem if it is only a 'small > part'? All that is needed is a simple fast library that handles the basics of variable > character length strings and allows simple look-ups against those stings. Ignoring any case > conversion problems. > > PROCESSING unicode data is the more complex part, but that should not require anything more > complex than the processes that are already in place. Running everything UTF-8 rather than ASCII > should be a lot more practical today than it was ten years ago. Conversion to and from UTF-8 is only > required on the edge, and is not part of the 'core' requirements. Just as in PHP5 people > could ignore 'locale' and simply work with a plain ASCII setup, the same applies to UTF-8 > these days. Essentially that is what people are currently doing with PHP5 to handle unicode. > > The complexity comes when one starts to add 'locale' in terms of normalizing, case > conversion and ordering of lists. This is not going to be solved by anything other than ICU at the > present time, so we are looking to bundling a suitable build of that with PHP6 and I am happy that > we have already identified that this may not be the build normally included in a target > distribution. That is not our problem - we use the configuration that is going to be right moving > forward. So all we are currently looking at is a bridge between the data objects modelled in ICU > with UTF-8 default and unicode strings used for the variables, array indices and the like in PHP > core. I wonder why you mix "unicode strings used for the variables” and "unicode strings used for … array indices”. Second is not a problem, as array-index name is just a string which can have any characters which string has. In case of unicode support that means any unicode string. Only variable names are problematic. -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc

Attachment: [application/pgp-signature] Message signed with OpenPGP using GPGMail signature.asc