[RFC] Deprecate and remove case-insensitive constants

6 years ago by Nikita Popov — view source

unread

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

6 years ago by Stanislav Malyshev — view source

unread

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

6 years ago by Nikita Popov — view source

unread

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

6 years ago by Zeev Suraski — view source

unread

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

6 years ago by Christoph M. Becker — view source

unread

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

6 years ago by Zeev Suraski — view source

unread

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

6 years ago by Stanislav Malyshev — view source

unread

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

6 years ago by Nikita Popov — view source

unread

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