Re: Revisiting case-sensitivity in PHP

On Mon, Jun 10, 2024 at 9:40 PM Ben Ramsey <ramsey@php.net> wrote: > > > 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 > In fact, it's definitely a BC break I would not personally vote for in 8.4. This isn't some minor thing squirreled away in a library--this is the core language, with wide impact. For this reason, I believe it should target 9.0. I will happily vote for this feature, as long as the patch is reasonable. The most obvious implementation is not very good, though. The engine uses lowercase names for case insensitivity. Namespaces are embedded into the type names. To lowercase the namespace but not the type name, one could do a reverse scan for a namespace separator on the type name, and then lowercase from the start to the index of the namespace separator. For example, " Psr\Log\LoggerInterface" needs to become "psr\log\LoggerInterface". The problem with this is that it's not really going to save CPU nor memory because it still has to lowercase the namespace. We could refactor the engine to store the namespace separately from the type name. This is a lot more work and will increase the size of some types, which might be difficult at a technical level. I can't think of other implementations right now. If nobody can come up with a better implementation, I think we should consider going with split-sensitivity on namespaces where it matches the sensitivity of the thing it is attached to. A namespaced class would have a case sensitive namespace but a namesped function would still have a case insensitive one.