Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100677
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.175 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <BY2PR02MB2986333DA75D8E49E444844AC6D0@BY2PR02MB298.namprd02.prod.outlook.com>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de> <BY2PR02MB2986333DA75D8E49E444844AC6D0@BY2PR02MB298.namprd02.prod.outlook.com>
Date: Sat, 16 Sep 2017 09:24:44 -0600
Message-ID: <CAFMT4NrS2OVvxNNJ2ujk_4=hcw3Okip+XGX8Wx3=-CYfHSDcvw@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, "internals@lists.php.net" <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)

> First, in the example referenced above, arguably, making all constants ca=
se insensitive would in fact be the better solution - as you likely don't w=
ant both sOmE_CoNsT and SOME_CONST, or more reaslitically - Some_Const and =
SOME_CONST to both exist in your app - a situation case sensitive constants=
 would happily let you do.   That said, I think the scenario of having two =
define()'s, both define the same constant with different casing is such an =
edge case we really shouldn't put too much emphasis on it.

This argument holds no water in my eyes.

1) Can you tell the difference between YEAR and =CE=A5EAR? I can't. That's
a Greek Capital Letter Upsilon, not a capital ASCII Y, in the latter.
This situation is worse and irreconcilable. People do this sort of
thing from time to time as obfuscation or for clever debugging
puzzles. It's not really an issue in practice because it's confusing
and so people avoid it.

2) sOmE_CoNsT would be absolutely terrible to type over and over.
Nobody will want to subject themselves to it. It might be done from
time to time just like the unicode abuse.

> Which brings me to the second thing - deprecating features - even if they=
 aren't the best features in the world - should only be considered if there=
's very substantial gain to be had.  Breaking compatibility has substantial=
 cost on our users, and consequently - on the PHP project.   While sometime=
s breaking compatibility is warranted - for security, reliability or perfor=
mance - it is, in general, something we ought to do our best to avoid if th=
ere isn't a strong case for it.

With all I've said I still agree here. Deprecating case-insensitive
constants *by itself* is not a substantial gain. This is why I opened
with my very first reply in this thread on a note of combining it with
other features that *would* be substantial. However, other people have
really wanted us to focus the discussion on deprecating case
insensitive constants only, and if that's what we do I'll be voting
"no". However it is something I really would like to see in connection
with other features or changes.