2024年6月11日(火) 23:18 Levi Morrison <levi.morri...@datadoghq.com>: > > On Mon, Jun 10, 2024 at 9:40 PM Ben Ramsey <ram...@php.net> wrote: > > > > > On Jun 10, 2024, at 20:35, Valentin Udaltsov > > > <udaltsov.valen...@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.
Hi I'm worried that have an impact on Windows (case-insensitive file system). Even if it's only the Class name. Looks like need to more discussion. Regards Yuya -- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------
