Re: [PHP-DEV] [RFC] Deprecate and remove case-insensitive constants

2018-07-04 Thread Stanislav Malyshev
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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DEV] [RFC] Deprecate and remove case-insensitive constants

2018-07-04 Thread Zeev Suraski


> -Original Message-
> From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
> Sent: Wednesday, July 4, 2018 8:00 PM
> To: Zeev Suraski ; Nikita Popov 
> Cc: Stanislav Malyshev ; Internals
> 
> 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  wrote:
> >
> >> On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev
> >> 
> >> 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


Re: [PHP-DEV] [RFC] Deprecate and remove case-insensitive constants

2018-07-04 Thread Christoph M. Becker
On 04.07.2018 at 17:02, Zeev Suraski wrote:

> On Wed, Jul 4, 2018 at 5:12 PM Nikita Popov  wrote:
> 
>> On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev 
>> 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]


-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Deprecate and remove case-insensitive constants

2018-07-04 Thread Zeev Suraski
On Wed, Jul 4, 2018 at 5:12 PM Nikita Popov  wrote:

> On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev 
> 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


Re: [PHP-DEV] [RFC] Deprecate and remove case-insensitive constants

2018-07-04 Thread Nikita Popov
On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev 
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


Re: [PHP-DEV] [RFC] Deprecate and remove case-insensitive constants

2018-06-25 Thread Stanislav Malyshev
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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] [RFC] Deprecate and remove case-insensitive constants

2018-06-24 Thread Nikita Popov
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