Re: Deprecate and remove case-insensitive constants?

From: Date: Wed, 13 Sep 2017 17:24:59 +0000
Subject: Re: Deprecate and remove case-insensitive constants?
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-100566@lists.php.net to get a copy of this message
On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <TonyMarston@hotmail.com> wrote: > "Sara Golemon" wrote in message > > news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com... >> +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 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 completely > 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

« previous php.internals (#100566) next »