Everything

php

[RFC] Deprecate and remove case-insensitive constants

php.internals

Nikita Popov

8 years ago

Hi internals,

I'd like to propose the deprecation (in PHP 7.3) and removal (in PHP 8) of
case-insensitive constants:

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.

Regards,
Nikita

Stas Malyshev

8 years ago

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.

--
Stas Malyshev
smalyshev@gmail.com

Nikita Popov

8 years ago

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

Zeev Suraski

8 years ago

On Wed, Jul 4, 2018 at 5:12 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
>
>
> 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.
>

Personally I think that the grounds for deprecating this particular feature
isn't very strong. Yes, we'd probably not do it this way if we were
starting from scratch, but is it that bad for us to make the migration to
PHP 8 a bit more difficult?  I'm not sure.  So I'm probably -1 on it, but
at the same time I don't think it's bad enough to warrant active
'campaigning' against this RFC :)

Zeev

Christoph Becker

8 years ago

On 04.07.2018 at 17:02, Zeev Suraski wrote:

> On Wed, Jul 4, 2018 at 5:12 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev <smalyshev@gmail.com>
>> wrote:
>>
>> 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.
>
> Personally I think that the grounds for deprecating this particular feature
> isn't very strong. Yes, we'd probably not do it this way if we were
> starting from scratch, but is it that bad for us to make the migration to
> PHP 8 a bit more difficult?  I'm not sure.  So I'm probably -1 on it, but
> at the same time I don't think it's bad enough to warrant active
> 'campaigning' against this RFC :)

In my humble opinion, the listed motivations[1] are more than sufficient
to get rid of this supposedly rarely used feature.

[1]
<https://wiki.php.net/rfc/case_insensitive_constant_deprecation#motivation>

--
Christoph M. Becker

Zeev Suraski

8 years ago

> -----Original Message-----
> From: Christoph M. Becker [mailto:cmbecker69@gmx.de]
> Sent: Wednesday, July 4, 2018 8:00 PM
> To: Zeev Suraski <vsuraski@gmail.com>; Nikita Popov <nikita.ppv@gmail.com>
> Cc: Stanislav Malyshev <smalyshev@gmail.com>; Internals
> <internals@lists.php.net>
> Subject: Re: [PHP-DEV] [RFC] Deprecate and remove case-insensitive constants
>
> On 04.07.2018 at 17:02, Zeev Suraski wrote:
>
> > On Wed, Jul 4, 2018 at 5:12 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> >
> >> On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev
> >> <smalyshev@gmail.com>
> >> wrote:
> >>
> >> 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.
> >
> > Personally I think that the grounds for deprecating this particular
> > feature isn't very strong. Yes, we'd probably not do it this way if we
> > were starting from scratch, but is it that bad for us to make the
> > migration to PHP 8 a bit more difficult?  I'm not sure.  So I'm
> > probably -1 on it, but at the same time I don't think it's bad enough
> > to warrant active 'campaigning' against this RFC :)
>
> In my humble opinion, the listed motivations[1] are more than sufficient to get
> rid of this supposedly rarely used feature.

Fair enough, I disagree (after of course having read the motivations) but again don't feel that strongly about it.  Realistically case insensitive constants are likely only used for global constants and not namespaced ones (namespaced code tends to go along with a more modern syntax guidelines).  So I think the first issue is probably mostly theoretical, the 2nd one is a fairly minor annoyance IMHO, and the performance impact is likely negligible in the grand scheme of things.  Not a huge bang for the buck in my humble opinion.

Zeev

Stas Malyshev

8 years ago

Hi!

> 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.

I think b) is completely fine (I don't think anybody needs a function
named "true" - would be very confusing anyway) and if a) proves a
problem, I still think special-casing may be a good solution.

So I'd go with this as the RFC proposal.

--
Stas Malyshev
smalyshev@gmail.com

Nikita Popov

8 years ago

On Sun, Jun 24, 2018 at 1:18 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> I'd like to propose the deprecation (in PHP 7.3) and removal (in PHP 8) of
> case-insensitive constants:
>
> 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.
>
> Regards,
> Nikita
>

Based on the received feedback, the RFC now specifies that true/false/null
will become reserved keywords rather than special-cased constants in PHP 8.
Should we run into some unexpected BC issues while doing that, we can
reconsider adding some special checks to mitigate impact.

Nikita