Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100557
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <3D.0C.10715.383F8B95@pb1.pair.com>
To: internals@lists.php.net
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de> <CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com>
In-Reply-To: <CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com>
Date: Wed, 13 Sep 2017 09:59:43 +0100
Lines: 6
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: TonyMarston@hotmail.com ("Tony Marston")

"Sara Golemon"  wrote in message 
news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com...
>
>On Tue, Sep 12, 2017 at 5:02 AM, Christoph M. Becker <cmbecker69@gmx.de> 
>wrote:
>> Even if these issues could be resolved, I still think allowing both
>> case-sensitive and case-insensitive constant identifiers does more harm
>> than good.
>>
>+0.1 to removing case-insensitive constants, though we'd need to
>define both "null" and "NULL" (similar for true and false) since
>there's little consensus on which version of these constants get used
>from project to project.  Also: While deprecating for 7.3 is fine, I'd
>favor waiting for 8.0 for full removal.
>
>As to François' suggestion to make the whole language case-sensitive?
>Yeesh, that feels like a much more aggressive movement.  In the case
>of constants they very nearly are case-sensitive only since, as you
>point out, common practice is to not pass true for that third
>parameter, and to prefer `const` over `define` anyway.  Identifiers
>are another matter since they're insensitive by default.
>
>In the case of classnames I could almost get on board since
>autoloading standards have pushed users naturally in the direction of
>respecting case sensitive as a coding standard.  I don't feel as
>though that's true of functions or of projects where autoloaders
>aren't used (not a small number).

You seem to forget that autoloading is an option, not a requirement. I don't 
use autoloading in my 14 year old framework for several reasons:
- An autoloader did not exist when I created my framework.
- I built an alternative mechanism into my framework, so I don't need an 
autoloader.
- I don't like the way autoloaders work - all my class names are in snake 
case (lowercase with underscore separators) and the autoloader converts '_' 
into '/' thus producing a file path which does not exist.

By convention I always use uppercase for constants which makes them 
instantly recognisable in my code as all other names are either completely 
lowercase or mixed case. Making constants case sensitive instead of 
insensitive would not affect me.

However, I would be totally against switching the rest of the language to be 
case sensitive for the following reasons:
- It would be a huge BC break no little or no benefit.
- It would allow developers to shoot themselves in the foot by having 
different functions with the same name but different mixtures of case, so 
that foo(), Foo() FOO() and fOO() would be treated as different functions.
- if people move from keyboard input to speech recognition, then simply 
speaking a name would not work - you would have to spell it out character by 
character, and specify either upper or lowercase for each character.

People who think that case sensitive software is cool are deluding 
themselves. When I started working on mainframe computers (UNIVAC and IBM) 
in the early 1970s everything was case-insensitive. This was only changed by 
people who did not understand the ramifications of their choice.

-- 
Tony Marston