Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100550
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.175 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <5a9001ea-2a3c-8ea6-d5ef-1da326009414@gmail.com>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de> <5a9001ea-2a3c-8ea6-d5ef-1da326009414@gmail.com>
Date: Tue, 12 Sep 2017 19:55:57 +0000
Message-ID: <CAESVnVpw3KCVLg+V7T0ghuM8kqotRfzwd4qw4429+n2D6EiJhA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: pollita@php.net (Sara Golemon)

On Tue, Sep 12, 2017 at 7:43 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> I don't think HHVM not supporting something can be an argument.
>
I agree there, though I will offer that part of the reason HHVM has
never bothered to support case-insensitive constants is that it's
simply never needed to.  The only major project that didn't work out
of the box was Wordpress, and when they saw my blogpost about their
one case-insensitive constant, they switched it to being
case-sensitive, because EVEN WORDPRESS thought they'd maintained that
BC long enough. :)

> I'm worried about TRUE vs. True vs. true though - I've see all of those used
> around the code (not tRuE though ;) and breaking that would add a ton of
> meaningless work to maintainers without any upside. Same with NULL/null etc.
>
We could always special case these in the lexer, or during
compile-time constant folding.  I agree they're a concern (and already
noted as much in my previous reply), but they're an entirely tractable
concern.

-Sara