Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100592
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de>
Date: Thu, 14 Sep 2017 21:53:36 +0800
Message-ID: <CAF+90c_J3d4ws18e+JnMbFj_a4Co5s=wjfBR==CHD3Y8Dc9jkA@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c05e6e6719b2c0559269af9"
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c05e6e6719b2c0559269af9
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 12, 2017 at 8:02 PM, Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> Hi everybody!
>
> Usually constant identifiers are treated case-sensitive in PHP.  This is
> always the case for constants defined via a `const` declaration.
> However, define() allows to pass TRUE as third argument to define a
> case-insensitive constant.  This feature appears to potentially result
> in confusion, and also causes bugs as shown in
> <https://bugs.php.net/74450>.  See an example created by Nikita to see
> some probably unexpected behavior: <https://3v4l.org/L6nCp>.
>
> Even if these issues could be resolved, I still think allowing both
> case-sensitive and case-insensitive constant identifiers does more harm
> than good, so either case-sensitive or case-insensitive constant
> identifiers should be removed from the language.  Since case-sensitive
> constant identifiers are already the default, and HHVM doesn't even
> support case-insensitive identifiers at all, I would suggest to remove
> case-insensitive constant identifiers.
>
> This could be implemented by triggering E_DEPRECATED whenever the third
> argument to define() is TRUE in PHP 7.3, and to remove this parameter
> altogether in PHP 8.  Most likely some further simplification in the
> engine could be done then as well.
>
> Thoughts?
>

+1 on doing this. I can understand having case-insensitive constants, but
having both case-sensitive and case-insensitive at the same time is weird
and rather useless. I imagine the only reason why this "feature" exists in
the first place is to support arbitrary casing for true/false/null, which
is better handled by special-casing these particular constants (something
we already do for various other reasons). This will simplify the language,
reduce implementation complexity on our side and resolve some bugs that are
infeasible to fix otherwise.

Nikita

--94eb2c05e6e6719b2c0559269af9--