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! -- Best regards, Valentin Udaltsov
