"Sara Golemon" wrote in message
news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=u_f3gd87rm...@mail.gmail.com...
On Tue, Sep 12, 2017 at 5:02 AM, Christoph M. Becker <cmbecke...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
