Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100615 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88361 invoked from network); 15 Sep 2017 09:25:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Sep 2017 09:25:43 -0000 X-Host-Fingerprint: 62.31.75.76 76.75-31-62.static.virginmediabusiness.co.uk Received: from [62.31.75.76] ([62.31.75.76:4948] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 57/CA-19300-69C9BB95 for ; Fri, 15 Sep 2017 05:25:42 -0400 Message-ID: <57.CA.19300.69C9BB95@pb1.pair.com> To: internals@lists.php.net References: <752eaf1d-5603-70f5-8e69-b8243547cad1@gmail.com> <320b3863-e36b-2ed4-543b-fcbd433b1c56@gmx.de> In-Reply-To: <320b3863-e36b-2ed4-543b-fcbd433b1c56@gmx.de> Date: Fri, 15 Sep 2017 10:25:37 +0100 Lines: 7 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 62.31.75.76 Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants? From: TonyMarston@hotmail.com ("Tony Marston") ""Christoph M. Becker"" wrote in message news:320b3863-e36b-2ed4-543b-fcbd433b1c56@gmx.de... > >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. You are missing a third option - Microsoft languages are case-preserving. This is where the IDE ensures that every use of a word is automatically switched to the case used in its original definition. This makes it impossible to use the same word with a different case. > 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: > > 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). Although the PHP manual says that constants are case-insensitive, it also says that by convention all constants are uppercase. I have been following that convention, so a change to make constants case sensitive instead of insensitive would not bother me. In fact it would not bother me if user-defined constants could only ever be in upper case as that would remove any possible confusion between 'foo' and 'Foo'. -- Tony Marston