Re: What "Unicode support" really means

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. -- 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