""Christoph M. Becker"" wrote in message
news:320b3863-e36b-2ed4-543b-fcbd433b1...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
