Re: Revisiting case-sensitivity in PHP
> On Jun 10, 2024, at 20:35, Valentin Udaltsov <[email protected]> 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
Thread (18 messages)