Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100542
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAFMT4NoeSKgNrFhLPgk3g_crzV1vWmV-kCXHS94UtNnQEQZyPA@mail.gmail.com>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de> <6601584d-c76d-4ed7-b4d6-b95e1b401cae@tekwire.net>
 <CAFMT4NoeSKgNrFhLPgk3g_crzV1vWmV-kCXHS94UtNnQEQZyPA@mail.gmail.com>
Date: Tue, 12 Sep 2017 08:55:50 -0600
Message-ID: <CAFMT4NqkowAojMhLfKtwmmFJ5uFukr73cpG4nO-x+_BpQVFMug@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"
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: levim@php.net (Levi Morrison)

> 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);

After rewriting my reply I noticed this sentence doesn't quite make sense:

> This is not just convenience; it provides safety to refactoring and
> general code analysis tools.

Instead I meant that using the string is not just inconvenient; it
also prevents fully-safe code refactoring and analysis.

> 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.