Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100624
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.15 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>,
 Nikita Popov <nikita.ppv@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de>
 <CAF+90c_J3d4ws18e+JnMbFj_a4Co5s=wjfBR==CHD3Y8Dc9jkA@mail.gmail.com>
 <752eaf1d-5603-70f5-8e69-b8243547cad1@gmail.com>
 <320b3863-e36b-2ed4-543b-fcbd433b1c56@gmx.de>
 <125e90c8-35f8-fbfc-67d1-29109ccb15a5@gmail.com>
Message-ID: <1be60fc9-fedf-b4a7-7963-94cd52b46f94@gmx.de>
Date: Fri, 15 Sep 2017 15:42:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <125e90c8-35f8-fbfc-67d1-29109ccb15a5@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 15.09.2017 at 01:34, Stanislav Malyshev wrote:

>>   <?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 think it is, see <https://bugs.php.net/bug.php?id=75211>.

> 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.

Thanks for pointing out my mistake.  I had a closer look and indeed
found that ext/interbase defines case-insensitive constants throughout.
The only other case-insensitive constants defined in a recent php-src
master seem to be TRUE, FALSE, NULL and SID.

With regard to mcrypt and interbase: the former has been deprecated as
of PHP 7.1.0[1], and the latter had originally been suggested for
removal as of PHP 7.0.0, but a maintainer stepped forward and so the
extension has been kept, but apparently they don't have the time to
maintain the extension anymore[2].  It seems to me that users of these
extensions have bigger issues than changing the case of the constants
(if this would even be necessary; they may well already have written
these in upper case).

And of course, there may be many more extensions defining
case-insensitive constants, and it appears to be practically impossible
to assess the resulting BC break if we remove this option.  However, I'm
not suggesting to remove it right away, but rather to deprecate
case-insensitive constants first.  Any peace of software that is
actively maintained should be able to cope with this change during the
course of some years.

Anyhow, sticking with the possibility to define case-insensitive
constants in extensions, but to remove the third parameter of define()
wouldn't help at all.

[1] <https://wiki.php.net/rfc/mcrypt-viking-funeral>
[2] <https://bugs.php.net/bug.php?id=72175>

-- 
Christoph M. Becker