Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100545
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <C6BCB3C4-E100-4171-8C2A-1A4870DF0665@gmail.com>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de> <6601584d-c76d-4ed7-b4d6-b95e1b401cae@tekwire.net>
 <CAFMT4NoeSKgNrFhLPgk3g_crzV1vWmV-kCXHS94UtNnQEQZyPA@mail.gmail.com> <C6BCB3C4-E100-4171-8C2A-1A4870DF0665@gmail.com>
Date: Tue, 12 Sep 2017 10:45:46 -0600
Message-ID: <CAFMT4No-hRr06WPco6+dUeqnMjkQB1pbexZ9jRiPGT06RS33fw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: levim@php.net (Levi Morrison)

> Apologies if I've completely missed the point here.

Oh well, it happens.

> Are you saying that without case sensitivity, the language could deduce t=
hat sum2 in that case was a function reference? That seems optimistic: not =
only can you have a class, a constant, and a function all with the same nam=
e, but you can't actually know which exists until the line is executed, bec=
ause all three can be defined at any time.

Close. If we make case sensitivity consistent (either all insensitive
or all sensitive) *and* merge symbol tables then we can get actual
features out of it. As it stands just changing the case sensitivity
does not buy as any features for our BC break.

The rest of my message only makes sense once you understand I was
proposing unified case sensitivity for all symbols *and* merging them
into one table.

>>    array_map(sum2, $input1, $input2);
>>
>>Currently that requires `sum2` to be a constant.
>
> I'm not clear what this has to do with case sensitivity; the problem here=
 is that we don't have a type of "function reference" (nor "class reference=
") so simulate such references with strings and runtime assertions.

This confusion stems from the aforementioned items.

> If we want function and class references, they should have their own, una=
mbiguous, syntax.

My point was rather that if we fix our inconsistency issues and merge
the tables no such syntax is required; all existing syntax works.
There are engine changes that have to accompany those as well,
obviously.

In summary I think changing constant case sensitivity is too small of
a step to gain us anything, but would be *very* happy to take it
further because it will give us actual features for our trouble.