Hi!
> It seems to me that this would miss the point, namely to introduce some
> consistency, and to be able to
If working code would be broken, nobody needs "consistency". I've built
tons of software, and never ever any single client asked me "but do you
have 'constistency'? Surely, I'm not against that warm fuzzy feeling
that some call "consistency", but not at the expense of breaking working
code.
> All programming languages that I know of are either case-sensitive or
> case-insensitive. PHP is the sole execption (CMIIW) – and the potential
> cognitive overhead during programming is hard to justify. Constants are
Would be very good argument if we were designing a new language called
"PHP". Unfortunately, we're about 20 years late to that. When we design
the next one, we'd be sure to take it into the account. For this one,
not breaking people's working code is IMO a much bigger and more useful
concern.
> <?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
It should fail, but that's not what we're discussing here.
> 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
We probably should not, but we should keep the ones that were there, if
they were. If you say that everybody already used CONST_CS then great. I
see however that some extensions (e.g. ibase and mcrypt) do not use that
flag.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
