Re: [RFC] Case sensitive PHP

From: 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.

« previous php.internals (#131355) next »