Re: [RFC] Case sensitive PHP
| From: | Seifeddine Gmati | Date: | Thu, 18 Jun 2026 02:35:59 +0000 |
| Subject: | Re: [RFC] Case sensitive PHP | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131355@lists.php.net to get a copy of this message | ||
> Is there a practical, real-world issue this solves? I have never in my life seen someone write
> STRLEN(). Drupal used to use TRUE/FALSE instead of true/false, but I don't know if
> they've ever changed that and it doesn't hurt anything. Class names everyone should
> already be treating as case sensitive because of the file system. And IDEs and SA tools have been
> pushing toward the "standard" casing of things for decades. I don't really see this
> as an issue to solve.
I think end users see no problem being solved here. And that's okay.
However, this change helps the engine (and any tool that deals with
PHP symbol definitions, analyzers, LSPs, etc.) by making symbol
management easier, as it removes the need for a folding pass required
on every identifier encountered.
This also helps make PHP more consistent, first, with other
programming languages, and secondly, with itself, since constants in
PHP are already case-sensitive, so making everything behave the same
is a win.
And as you said, no one writes
STRLEN, and people write code
assuming that the casing they are using is correct per definition, not
for style reasons. The deprecation phase would help people spot
incorrect casings in their application for now, until the 9.0 upgrade.
Cheers,
Seifeddine.