Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100608
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.169 as permitted sender)
To: "Christoph M. Becker" <cmbecker69@gmx.de>,
 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>
Message-ID: <125e90c8-35f8-fbfc-67d1-29109ccb15a5@gmail.com>
Date: Thu, 14 Sep 2017 16:34:55 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <320b3863-e36b-2ed4-543b-fcbd433b1c56@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> It seems to me that this would miss the point, namely to introduce some
> consistency, and to be able to

If working code would be broken, nobody needs "consistency". I've built
tons of software, and never ever any single client asked me "but do you
have 'constistency'? Surely, I'm not against that warm fuzzy feeling
that some call "consistency", but not at the expense of breaking working
code.

> 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

Would be very good argument if we were designing a new language called
"PHP". Unfortunately, we're about 20 years late to that. When we design
the next one, we'd be sure to take it into the account. For this one,
not breaking people's working code is IMO a much bigger and more useful
concern.

>   <?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 completely fail to see why we should retain the possibility to define
> case-insensitive constants in extensions.  Deprecate that for PHP 7.3.0

We probably should not, but we should keep the ones that were there, if
they were. 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.
-- 
Stas Malyshev
smalyshev@gmail.com