Re: Revisiting case-sensitivity in PHP

> On Jun 10, 2024, at 20:35, Valentin Udaltsov <udaltsov.valentin@gmail.com> wrote: > > Hi, internals! > > 9 years have passed since the last discussions of case sensitive PHP: > https://externals.io/message/79824 and > https://externals.io/message/83640. > Here I would like to revisit this topic. > > What is case-sensitive in PHP 8.3: > - variables > - constants (all since > https://wiki.php.net/rfc/case_insensitive_constant_deprecation) > - class constants > - properties > > What is case-insensitive in PHP 8.3: > - namespaces > - functions > - classes (including self, parent and static relative class types) > - methods (including the magic ones) > > Pros: > 1. no need to convert strings to lowercase inside the engine for name lookups (a small > performance and memory gain) > 2. better fit for case sensitive platforms that PHP code is mostly run on (Linux) > 3. uniform handling of ASCII and non-ASCII symbols (currently non-ASCII symbols in names are > case sensitive: https://3v4l.org/PWkvG) > 4. PSR-4 compatibility > (https://www.php-fig.org/psr/psr-4/#:~:text=All%20class%20names%20MUST%20be%20referenced%20in%20a%20case%2Dsensitive%20fashion) > > Cons: > 1. pain for users, obviously > 2. a backward compatibility layer might be difficult to implement and/or have a performance > penalty > > On con 1. I think today PHP users are much more prepared for the change: > - more and more projects adopted namespaces and PSR-4 autoloading via Composer that never > supported case-insensitivity (https://github.com/composer/composer/issues/1803, > https://github.com/composer/composer/issues/8906) which forced to > mind casing > - static analyzers became more popular and they do complain about the wrong casing (see > https://psalm.dev/r/fbdeee2f38 and > https://phpstan.org/r/1789a32d-d928-4311-b02e-155dd98afbd4) > - Rector appeared (it can be used to automatically prepare the codebase for the next PHP > version) > > On con 2. While considering different transition options proposed in prior discussions > (compilation flag, ini option, deprecation notice) I stumbled upon Nikita's comment > (https://externals.io/message/79824#79939): > May I recommend to only target class and class-like names for an initial RFC? Those have the > strongest argument in favor of case-sensitivity given > how current autoloader implementations work - essentially the case-insensitivity doesn't > properly work anyway in modern code....I'd also appreciate having a voting option for removing > case-insensitivity right away, as opposed to throwing E_STRICT/E_DEPRECATED. If we want to change > this, I personally would rather drop it right away than start throwing E_STRICT warnings that would > make the case-insensitive usage impossible anyway. > It makes a lot of sense to me: a fairly simple change in the core and no performance penalty. > At the same time, a gradual approach will reduce the stress. > > So the plan for 8.4 might be to just drop case insensitivity for class names and that's > it... Let's discuss that! I’m not saying I agree with or support this, but I think your proposal has a better chance of being accepted if you target PHP 9.0 instead of 8.4. Cheers, Ben

Attachment: [application/pgp-signature] Message signed with OpenPGP signature.asc