Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100710
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lsces.co.uk designates 185.153.204.204 as permitted sender)
To: internals@lists.php.net
References: <da7da5b0-2fc1-b92c-aaa9-b39413b000f7@lsces.co.uk>
 <ec760155-7d65-14e5-8d7c-3008749b0ab9@gmail.com>
Message-ID: <2307c713-df4a-f27b-602b-86ea740f22a9@lsces.co.uk>
Date: Wed, 20 Sep 2017 10:32:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <ec760155-7d65-14e5-8d7c-3008749b0ab9@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Progress or just 'a mess'?
From: lester@lsces.co.uk (Lester Caine)

On 20/09/17 08:26, Stanislav Malyshev wrote:
>> picking up on the base problem? Just what character set is PHP7 designed
>> to work with.
> 
> What do you mean by "work with"?

Actually that HAS already been identified in this thread, and it is only
the basic ASCII character set, but this is not actually specified anywhere?

>> For PHP8 is it not time to lay out a similar set of rules as provided by
>> SQL and identify just what 'case-insensitive' means and where it does apply?
> 
> I'm not sure which problem you are trying to solve here. Could you
> explain what you'd be using these rules for?

Having established that the only characters that are case-insensitive in
PHP7 ... the unicode basic latin set ... the discussion SHOULD be on
either expanding that to cover all case folding or simply removing this
rather limited case? Tony Marston is making an impassioned demand to
retain this very limited case, and therefore expand it to cover all
character sets, and as a fellow 'English only' coder, I can accept that
argument. However many of my clients do not use English as a first
language so any data handling has to be unicode based, and case in that
data can be important, so is case-insensitive really as universal as
Tony thinks? Certainly we need data case-insensitivity to handle unicode
properly and not just a few english characters ( should I really add a
capital 'E' to english just to please the spell checker? )

People are using their own languages when writing PHP variables and
function names, and apart from a few edge cases this does seem to be
working for them. As with SQL, the key programming words are in English,
and I don't think anybody would suggest adding aliases for them, so
restricting keywords to 'unicode basic latin set' can be defined, but
does THEN making that case-insensitive add to the problems of making PHP
more user friendly in handling unicode names elsewhere? I am seeing SQL
field names coming in with unicode content, and these are then array
keys in PHP ... the latin characters get lower cased at times and this
DOES cause a problem if the metadata defines upper case and I suspect
that is something that will never be changed now, but the actual rules
applied would be nice to know?

-- 
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