Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100553
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
To: Levi Morrison <levim@php.net>, =?UTF-8?Q?Fran=c3=a7ois_Laupretre?=
 <francois@tekwire.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de>
 <6601584d-c76d-4ed7-b4d6-b95e1b401cae@tekwire.net>
 <CAFMT4NoeSKgNrFhLPgk3g_crzV1vWmV-kCXHS94UtNnQEQZyPA@mail.gmail.com>
Message-ID: <d3f50a6b-f89b-542b-b2ba-e468c15f0ccc@gmx.de>
Date: Tue, 12 Sep 2017 23:32:33 +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: <CAFMT4NoeSKgNrFhLPgk3g_crzV1vWmV-kCXHS94UtNnQEQZyPA@mail.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 12.09.2017 at 16:52, Levi Morrison wrote:

> On Tue, Sep 12, 2017 at 6:52 AM, François Laupretre
> <francois@tekwire.net> 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
  <?php
  const FOO = 'bar';
  ?>

  b.php
  <?php
  define('FOO', 'baz', 1); // => 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