Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.41 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <52E59883.5060200@ajf.me>
References: <52E55D0F.3030308@ajf.me>
	<CAGAGxbZAgEf7_FSHqnE=w3Xy=eozfcGzTOgr4QsCw_Uj1_f87Q@mail.gmail.com>
	<52E59883.5060200@ajf.me>
Date: Sun, 26 Jan 2014 23:57:00 +0000
Message-ID: <CAGAGxbY09BmTQCPJO=NmaY==ptp2hA_9jBkm69iAXfq5WKcuWg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Chris Wright <daverandom@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP and case-sensitivity inconsistency in PHP 6
From: daverandom@php.net (Chris Wright)

On 26 January 2014 23:21, Andrea Faulds <ajf@ajf.me> wrote:
> Why's that silly? The uppercase form of =DF is SS. PHP isn't case-insensi=
tive
> at the moment, merely case-insensitive for ASCII only.
>

This alters the issue somewhat - it opens up the unicode can of worms
and it's almost completely unresolvable without changing the rules for
identifiers fundamentally. At the moment identifiers can be ASCII
[a-zA-Z0-9] plus >=3D0x80, but no case translation is performed outside
the bounds of ASCII [a-zA-Z0-9] - if we were to start interpolating
case outside these bounds the a) we'd need to pick a standard set of
valid code points (presumably unicode?) and we'd need to start doing
some (relatively) complex validation of names.

> On a different note, your case-sensitive at declare, case-insensitive at =
use
> approach would not work well for consistency. Consider variables, for
> example. There is no difference (except for static variables, I suppose)
> between declaration and usage when we're dealing with assignments. Hence
> we'd have to have two sets of rules: Semi-case-insensitivity for function=
s,
> and case-sensitivity for variables. Yuck. I'd rather pick one system
> (preferably case-insensitivity) and use it everywhere.

This is true, but essentially what I'm suggesting is that the check is
performed at the point where an entry is created in the relevant
symbol table - if an operation would end up creating a thing that
already exists with a different casing, blow up. This is already what
happens for function/class etc declarations, I'm just suggesting
extending this to variables.

Thanks, Chris