Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123583
Precedence: bulk
MIME-Version: 1.0
References: <CAPyeZ4O2rK+2ApuE-YLc7j_Z2LcT29yHcLYXvB0oGs-D_zTSag@mail.gmail.com>
 <D0449280-7113-48A3-979B-7995051B622C@php.net> <CAAKU0ukrRTWiaNXgD+OLHYGaUaE9V4k4m4Xxi=CLN8Te03UMTw@mail.gmail.com>
In-Reply-To: <CAAKU0ukrRTWiaNXgD+OLHYGaUaE9V4k4m4Xxi=CLN8Te03UMTw@mail.gmail.com>
Date: Tue, 11 Jun 2024 23:31:25 +0900
Message-ID: <CAEPPVa0EPG8pGcUkRv1J4FsS4rZg4dWO5Zarjr6hiss0tJTnKw@mail.gmail.com>
Subject: Re: [PHP-DEV] Revisiting case-sensitivity in PHP
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: youkidearitai@gmail.com (youkidearitai)

2024=E5=B9=B46=E6=9C=8811=E6=97=A5(=E7=81=AB) 23:18 Levi Morrison <levi.mor=
rison@datadoghq.com>:
>
> On Mon, Jun 10, 2024 at 9:40=E2=80=AFPM 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_cons=
tant_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 ru=
n on (Linux)
> > > 3. uniform handling of ASCII and non-ASCII symbols (currently non-ASC=
II symbols in names are case sensitive: https://3v4l.org/PWkvG)
> > > 4. PSR-4 compatibility (https://www.php-fig.org/psr/psr-4/#:~:text=3D=
All%20class%20names%20MUST%20be%20referenced%20in%20a%20case%2Dsensitive%20=
fashion)
> > >
> > > 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 chan=
ge:
> > > - more and more projects adopted namespaces and PSR-4 autoloading via=
 Composer that never supported case-insensitivity (https://github.com/compo=
ser/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 codeba=
se for the next PHP version)
> > >
> > > On con 2. While considering different transition options proposed in =
prior discussions (compilation flag, ini option, deprecation notice) I stum=
bled upon Nikita's comment (https://externals.io/message/79824#79939):
> > > May I recommend to only target class and class-like names for an init=
ial RFC? Those have the strongest argument in favor of case-sensitivity giv=
en
> > > how current autoloader implementations work - essentially the case-in=
sensitivity doesn't properly work anyway in modern code....I'd also appreci=
ate having a voting option for removing case-insensitivity right away, as o=
pposed to throwing E_STRICT/E_DEPRECATED. If we want to change this, I pers=
onally would rather drop it right away than start throwing E_STRICT warning=
s 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 t=
he stress.
> > >
> > > So the plan for 8.4 might be to just drop case insensitivity for clas=
s names and that's it... Let's discuss that!
> >
> >
> > I=E2=80=99m not saying I agree with or support this, but I think your p=
roposal 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

--=20
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------