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). Overall: No. I'm -1 on making non-constant identifiers case-sensitive. At best, I'd perhaps get on board with a declare(case_sensitivity=1); style directive. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
