Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100566
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.176 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <3D.0C.10715.383F8B95@pb1.pair.com>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de> <CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com>
 <3D.0C.10715.383F8B95@pb1.pair.com>
Date: Wed, 13 Sep 2017 17:24:59 +0000
Message-ID: <CAESVnVp6OKB64WuO9iKEP=L9-QrrFjS+kcoeKYKULRUff-RitQ@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: pollita@php.net (Sara Golemon)

On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <TonyMarston@hotmail.com> wro=
te:
> "Sara Golemon"  wrote in message
> news:CAESVnVpUkM_W9xF+0Qt=3D2M61dGy40gtOehFo=3DU_F3gd87rmxrQ@mail.gmail.c=
om...
>> +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=C3=A7ois' suggestion to make the whole language case-sensitiv=
e?
>> 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 forget any such thing.  I noted it as a phenomenon which has
*pushed* users in a particular direction, but by no means have all
users gone that way, as you note about yourself. Indeed, I have a 10
year old framework still in use at a previous company which does many
similar things for many similar reasons.

I also stated that I could *almost* get on board.  Almost is not 100%,
it's arguably not even 50% since it implies not actually crossing some
minimum required threshold.

> - 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.
>
Nit; That's autoloader specific.  PSR-0 defines that behavior, but
PSR-4 does not, for example.

> By convention I always use uppercase for constants which makes them
> instantly recognisable in my code as all other names are either completel=
y
> lowercase or mixed case. Making constants case sensitive instead of
> insensitive would not affect me.
>
Agreed, nor I suspect would it effect most other users regardless of
which case they use since the trend is to not use case-insensitive
constants in the first place.

> 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.
>
Yeah, decades of C/C++/Java developers are so dumb, like... fer reals.
Friggin' script kiddies, the lot of 'em.

-Sara