Re: What "Unicode support" really means

Pierre Joye wrote:

On Sun, Mar 9, 2014 at 11:44 PM, Lester Caine <lester@lsces.co.uk> wrote:

I don't think those two necessarily go together. Personally I think that making everything case sensitive is the first step to allowing Unicode identifier names. Then it is easy to say that names simply match so that 'normalization' is not a problem either! Just make strings with any different set of bytes a different string.

I'm totally not in favor of allowing Unicode identifiers and I see little gain in case sensitive names, it brings very little gains.

I think this is the one area that we need to have a vote on to set a couple of ground rules to move forward. 1 - Unicode identifiers 2 - Case sensitivity Until there is some agreement here I don't think that the next stage can be taken forward. But I would say that I always viewed PHP6 as unicode in the core, I don't see tying a developers hand up their back by requiring them to think up English versions of variable/function names. I don't see that 'normalizing' or other unicode problems come into that.

That said, mbstring is not a good solution for handling variable content. PHP needs to have proper Unicode support that doesn’t cause confusion and that allows people to write modern web apps that can handle Unicode text properly, without too much difficulty. At present we have a standard library of string functions which don’t necessarily work correctly with Unicode text. This has to change.

Yep - personally I don't use mbstring despite all web pages being UTF-8 and have been or many years. I use the database to handle the difficult stuff and then just pump 'clean' unicode down the pipe. The problem I am trying to untangle is the simple fact that database field names are now unicode, and I need to disbale anything that tries to use them for 'magic' purposes in PHP,

I do not know any databases not supporting the "as" keyword in one way or another. But even then, it is not really a PHP problem. Even ORM can solve this relatively easily using the right conversions.

So above ... There has already been discussion on this the other way around ... use 'AS' to allow unicode to be used in SQL. Restrict procedural/function code to using only using ASCII names to go with the ASCII reserved words, but it's just another strange hack!

which is difficult since all the data is returned as associative strings, and switching to numeric returns simply pushes the problem elsewhere :(

Also, while the database part of the Unicode support is important, we still did not solve the core problems...

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