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

This is only part of a thread. view whole thread
  100549
September 12, 2017 19:43 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> case-insensitive constant. This feature appears to potentially result > in confusion, and also causes bugs as shown in > <https://bugs.php.net/74450>. See an example created by Nikita to see > some probably unexpected behavior: <https://3v4l.org/L6nCp>.
The latter case probably should be fixed by not allowing second constant to be defined. If you already have case-insensitive constant, it should cover all of those.
> Even if these issues could be resolved, I still think allowing both > case-sensitive and case-insensitive constant identifiers does more harm > than good, so either case-sensitive or case-insensitive constant > identifiers should be removed from the language. Since case-sensitive > constant identifiers are already the default, and HHVM doesn't even > support case-insensitive identifiers at all, I would suggest to remove > case-insensitive constant identifiers.
I don't think HHVM not supporting something can be an argument. 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. I am also not convinced those constants are really that bad. I'd probably be fine with phasing out manual defines for case-insensitives though. But I'm not sure what purpose it would serve then - the engine would still have to support it, no? -- Stas Malyshev smalyshev@gmail.com
  100550
September 12, 2017 19:55 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
  100552
September 12, 2017 21:02 cmbecker69@gmx.de ("Christoph M. Becker")
On 12.09.2017 at 21:55, Sara Golemon wrote:

> On Tue, Sep 12, 2017 at 7:43 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote: > >> 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.
Sorry, I forgot to mention these special constants which are reserved words right now. Of course, these have to stay case-insensitive, and we simply could promote them to keywords which are case-insensitive, anyway. -- Christoph M. Becker