Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100607
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 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>
Message-ID: <320b3863-e36b-2ed4-543b-fcbd433b1c56@gmx.de>
Date: Fri, 15 Sep 2017 00:55:24 +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: <752eaf1d-5603-70f5-8e69-b8243547cad1@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 14.09.2017 at 23:22, Stanislav Malyshev wrote:

> [Nikita wrote]
>
>> +1 on doing this. I can understand having case-insensitive constants, but
>> having both case-sensitive and case-insensitive at the same time is weird
>> and rather useless. I imagine the only reason why this "feature" exists in
>> the first place is to support arbitrary casing for true/false/null, which
>> is better handled by special-casing these particular constants (something
>> we already do for various other reasons). This will simplify the language
> 
> If we support all case-insensitive constants that are predefined (not
> sure if any exts do that but we have to support those too if they do)
> then I don't see a big problem in phasing-out user-defined ones.

It seems to me that this would miss the point, namely to introduce some
consistency, and to be able to

> [Nikita continued]
>
>> reduce implementation complexity on our side and resolve some bugs
>> that are infeasible to fix otherwise.

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
the icing on the cake: they can be either case-insensitive or
case-sensitive at the discression of the dev defining the constant.
Using an extension which defines case-insensitive constants might raise
the following issue:

  <?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
constant afterwards?  Ah, yes, `foo`, of course!  The PHP manual
explains that quite clearly, so there must be a bug in my IDE and the
docs of the extension.  Oh, it's home time – I'm going to enjoy a nice
evening reading Brainf*ck code… ;)

FTR: there are 2811 occurances of REGISTER_\w+\_CONSTANT in current
php-src master, all of which use CONST_CS.  phpinternalsbook.com
mentions succinctly:

| The flags are mixed OR operation between CONST_CS (case-sensitive
| constant, what we want), […]

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
(which is more than a year away) and remove in PHP 8.0.0 (which might be
several years away) seems to be acceptable.  IMHO we should strive to
remove accidental complexity as soon as possible (and clearly, this is
not essential complexity).

-- 
Christoph M. Becker