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

This is only part of a thread. view whole thread
September 12, 2017 21:32 ("Christoph M. Becker")
On 12.09.2017 at 16:52, Levi Morrison wrote:

> On Tue, Sep 12, 2017 at 6:52 AM, François Laupretre > <> wrote: >> >> Le 12/09/2017 à 14:02, Christoph M. Becker a écrit : >> >>> 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. >>> >>> This could be implemented by triggering E_DEPRECATED whenever the third >>> argument to define() is TRUE in PHP 7.3, and to remove this parameter >>> altogether in PHP 8. Most likely some further simplification in the >>> engine could be done then as well. > > […] However, if we change only the case > sensitivity of constants we gain little value for our BC break.
I have not suggested to *change* the case sensivity of constants, but rather to settle on a common case – since `const` constants are always case-sensitive, it appears that this should be so for define'd constants. This would make code as the following to work as expected: a.php b.php true echo FOO; // => bar - WFT? ?> And it obviously would fix a bug. IMHO, that is sufficient gain for a presumably moderate BC break. Please note, that I do not want to pursue a discussion regarding changing all constants to be case-sensitive or all functions and class names to be case-insensitive. Of course, it is fine to discuss it, but it is clearly out of scope for what I'm trying to improve (in my opinion) here, which is more in the "a bird in the hand is worth two in the bush" corner. If it will be decided that all constant identifiers should be case-insensitive, I'd be fine with it (not happy, though). Probably, I should reword the RFC to reflect that it is actually about deprecation and removal of the third parameter of define() (plus preventing any extension to register constants which do not conform to the "default" casing). In short: don't have two kinds of constants wrt. spelling (true, false, null are not covered, since they are special anyway and could be promoted to keywords). -- Christoph M. Becker -- Christoph