Re: Deprecate and remove case-insensitive constants?

""Christoph M. Becker"" wrote in message news:320b3863-e36b-2ed4-543b-fcbd433b1c56@gmx.de...

On 14.09.2017 at 23:22, Stanislav Malyshev wrote:

[Nikita wrote]

+1 on doing this. I can understand having case-insensitive constants, but having both case-sensitive and case-insensitive at the same time is weird and rather useless. I imagine the only reason why this "feature" exists in the first place is to support arbitrary casing for true/false/null, which is better handled by special-casing these particular constants (something we already do for various other reasons). This will simplify the language

If we support all case-insensitive constants that are predefined (not sure if any exts do that but we have to support those too if they do) then I don't see a big problem in phasing-out user-defined ones.

It seems to me that this would miss the point, namely to introduce some consistency, and to be able to

[Nikita continued]

reduce implementation complexity on our side and resolve some bugs that are infeasible to fix otherwise.

All programming languages that I know of are either case-sensitive or case-insensitive.

You are missing a third option - Microsoft languages are case-preserving. This is where the IDE ensures that every use of a word is automatically switched to the case used in its original definition. This makes it impossible to use the same word with a different case.

PHP is the sole execption (CMIIW) – and the potential cognitive overhead during programming is hard to justify. Constants are the icing on the cake: they can be either case-insensitive or case-sensitive at the discression of the dev defining the constant. Using an extension which defines case-insensitive constants might raise the following issue: <?php define('FOO', true, true); // public const in ext; transcript from C const FOO = false; // in global app code Why doesn't that fail? How am I supposed to write the extension constant afterwards? Ah, yes, foo, of course! The PHP manual explains that quite clearly, so there must be a bug in my IDE and the docs of the extension. Oh, it's home time – I'm going to enjoy a nice evening reading Brainf*ck code… ;) FTR: there are 2811 occurances of REGISTER_\w+\_CONSTANT in current php-src master, all of which use CONST_CS. phpinternalsbook.com mentions succinctly: | The flags are mixed OR operation between CONST_CS (case-sensitive | constant, what we want), […] I completely fail to see why we should retain the possibility to define case-insensitive constants in extensions. Deprecate that for PHP 7.3.0 (which is more than a year away) and remove in PHP 8.0.0 (which might be several years away) seems to be acceptable. IMHO we should strive to remove accidental complexity as soon as possible (and clearly, this is not essential complexity).

Although the PHP manual says that constants are case-insensitive, it also says that by convention all constants are uppercase. I have been following that convention, so a change to make constants case sensitive instead of insensitive would not bother me. In fact it would not bother me if user-defined constants could only ever be in upper case as that would remove any possible confusion between 'foo' and 'Foo'. -- Tony Marston