Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102573
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4b90f1d7-62ce-337c-42d7-d77743a979df@gmail.com>
References: <CAF+90c8kdruJHDu9tXSOrc6L+v8-nQ1x1UjD4dqPiWP9eCvQ1Q@mail.gmail.com>
 <4b90f1d7-62ce-337c-42d7-d77743a979df@gmail.com>
Date: Wed, 4 Jul 2018 16:12:13 +0200
Message-ID: <CAF+90c81VfoktLWjNsKwnBPVfbGdr-NARCsAydcoqYO-76QVeg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000782f3c05702d0490"
Subject: Re: [PHP-DEV] [RFC] Deprecate and remove case-insensitive constants
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000782f3c05702d0490
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > https://wiki.php.net/rfc/case_insensitive_constant_deprecation
> >
> > This was already discussed some time ago on the list, though that
> > discussion degenerated into unfortunate directions. I'd very much
> > appreciate if we could keep discussions on making PHP fully
> case-sensitive
> > or fully case-insensitive outside of this thread. (Feel free to open a
> new
> > one though.)
> >
> > The main point I'd like to have feedback on is the handling of true,
> false
> > and null, as I'm not sure what the best approach regarding that is.
>
> I think the must is to keep true/false/null working in all cases. I
> don't think messing with this would be acceptable due to amount of code
> it'd break.
>
> Now, I think breaking constant("null") could be acceptable in PHP 8, if
> necessary, as use case for this seems to be very narrow. However, I
> wonder if we can't just special-case those three in constant() function
> and write "for historical raisins, this is weird" and be done with it.
> Not ideal, but practically might be good enough.
>
> Converting them to keywords should be fine - am I wrong to think the
> impact would not be that big with new parser, as we now have less places
> where keywords are banned?
>
> As for the rest, I think we should get rid of case-insensitive constants
> (including defined by extensions) and all the weirdness that follows.
> Deprecating them would be a good first step.
>

Regarding making true/false/null reserved keywords, the state is as follows:

 * true/false/null are already reserved class names, so they cannot be used
as class names already (no BC break here).
 * Method and class constant names are not subject to reserved keyword
restrictions (no BC break here).
 * Global constants (e.g. in namespaces) already check against
true/false/null, though there are unintentional loopholes (no BC break
here).
 * Function names can still use true/false/null right now.

So basically the practical BC impact of making them reserved keywords would
only be a) cannot be used via constant() anymore and b) can't declare
global functions with these names.

Given that making them reserved keywords is otherwise the cleanest
solution, I think we should go with that.

Are there any other opinions on this topic or the RFC in general? I'm a bit
surprised that there are so little comments after the somewhat explosive
discussion last time around.

Nikita

--000000000000782f3c05702d0490--