Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100541
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <6601584d-c76d-4ed7-b4d6-b95e1b401cae@tekwire.net>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de> <6601584d-c76d-4ed7-b4d6-b95e1b401cae@tekwire.net>
Date: Tue, 12 Sep 2017 08:52:38 -0600
Message-ID: <CAFMT4NoeSKgNrFhLPgk3g_crzV1vWmV-kCXHS94UtNnQEQZyPA@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: levim@php.net (Levi Morrison)

On Tue, Sep 12, 2017 at 6:52 AM, Fran=C3=A7ois Laupretre
<francois@tekwire.net> wrote:
> Hi,
>
> Le 12/09/2017 =C3=A0 14:02, Christoph M. Becker a =C3=A9crit :
>>
>> Hi everybody!
>>
>> Usually constant identifiers are treated case-sensitive in PHP.  This is
>> always the case for constants defined via a `const` declaration.
>> However, define() allows to pass TRUE as third argument to define a
>> 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>.
>>
>> 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.
>>
>> Thoughts?
>
>
> What about making PHP 8 100% case-sensitive (except true/false) ? If we
> announce it years in advance, it is possible, IMO.
>
> Regards
>
> Fran=C3=A7ois
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

By itself this change provides little value. If it was done in
connection with other features such as merging symbol tables then we
can actually gain some significant improvements:

    array_map(sum2, $input1, $input2);

Currently that requires `sum2` to be a constant. To get the correct
behavior we currently need to do:

    array_map('fully\qualified\namespace\sum2', $input1, $input2);

This is not just convenience; it provides safety to refactoring and
general code analysis tools. Maintenance is a crucial aspect of large
code bases and being able to move away from stringly-typed things is a
significant improvement. It's also a step towards general autoloading
instead of just class/trait/interface autoloading; however this would
require further changes.

I believe these improvements would be worth it and do understand it is
a large backwards compatibility break. Given sufficient time and
tooling to prepare I think PHP would be markedly better in the
long-run for these two changes. However, if we change only the case
sensitivity of constants we gain little value for our BC break.