Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123573
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 11 Jun 2024 03:35:19 +0300
Message-ID: <CAPyeZ4O2rK+2ApuE-YLc7j_Z2LcT29yHcLYXvB0oGs-D_zTSag@mail.gmail.com>
Subject: [PHP-DEV] Revisiting case-sensitivity in PHP
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006cf903061a927158"
From: udaltsov.valentin@gmail.com (Valentin Udaltsov)

--0000000000006cf903061a927158
Content-Type: text/plain; charset="UTF-8"

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

--0000000000006cf903061a927158
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi, internals!<br><br>9 years have passed since the last d=
iscussions of case sensitive PHP:=C2=A0<a href=3D"https://externals.io/mess=
age/79824">https://externals.io/message/79824</a> and <a href=3D"https://ex=
ternals.io/message/83640">https://externals.io/message/83640</a>.<div>Here =
I would like to revisit this topic.<div><br></div><div><div>What is case-se=
nsitive in PHP 8.3:</div><div>- variables</div>- constants (all since <a hr=
ef=3D"https://wiki.php.net/rfc/case_insensitive_constant_deprecation">https=
://wiki.php.net/rfc/case_insensitive_constant_deprecation</a>)<div>- class =
constants</div><div>- properties<br></div><div><br></div><div>What is case-=
insensitive in PHP=C2=A08.3:</div><div>- namespaces<br><div>- functions<br>=
- classes (including self, parent and static relative class types)</div><di=
v><div>- methods (including the magic ones)</div><div><br></div><div>Pros:<=
/div><div>1. no need to convert strings to lowercase inside the engine for =
name lookups (a small performance and memory gain)</div><div>2. better fit =
for case sensitive platforms that PHP code is mostly run on (Linux)</div><d=
iv>3. uniform handling of=C2=A0ASCII and non-ASCII symbols (currently non-A=
SCII symbols in names are case sensitive: <a href=3D"https://3v4l.org/PWkvG=
">https://3v4l.org/PWkvG</a>)</div><div>4. PSR-4 compatibility (<a href=3D"=
https://www.php-fig.org/psr/psr-4/#:~:text=3DAll%20class%20names%20MUST%20b=
e%20referenced%20in%20a%20case%2Dsensitive%20fashion">https://www.php-fig.o=
rg/psr/psr-4/#:~:text=3DAll%20class%20names%20MUST%20be%20referenced%20in%2=
0a%20case%2Dsensitive%20fashion</a>)</div><div><br></div><div>Cons:</div><d=
iv>1. pain for users, obviously</div><div>2. a backward compatibility layer=
 might be difficult to implement and/or have a performance penalty</div><di=
v><br></div><div>On con 1. I think today PHP users are much more prepared f=
or the change:</div><div>- more and more projects adopted namespaces and PS=
R-4 autoloading via Composer that never supported case-insensitivity (<a hr=
ef=3D"https://github.com/composer/composer/issues/1803">https://github.com/=
composer/composer/issues/1803</a>, <a href=3D"https://github.com/composer/c=
omposer/issues/8906">https://github.com/composer/composer/issues/8906</a>) =
which forced to mind casing<br>- static analyzers became more popular and t=
hey do complain about the wrong=C2=A0casing (see <a href=3D"https://psalm.d=
ev/r/fbdeee2f38">https://psalm.dev/r/fbdeee2f38</a> and <a href=3D"https://=
phpstan.org/r/1789a32d-d928-4311-b02e-155dd98afbd4">https://phpstan.org/r/1=
789a32d-d928-4311-b02e-155dd98afbd4</a>)<br>- Rector appeared=C2=A0(it can =
be used to automatically prepare the codebase for the next PHP version)<br>=
</div><div><br></div><div>On con 2.=C2=A0<span style=3D"white-space-collaps=
e: preserve;">While considering different transition options proposed in pr=
ior discussions (compilation flag, ini option, deprecation notice) I stumbl=
ed upon Nikita&#39;s comment (</span><a href=3D"https://externals.io/messag=
e/79824#79939">https://externals.io/message/79824#79939</a><span style=3D"w=
hite-space-collapse: preserve;">)</span>:</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">May I recommend to only target class and class-like n=
ames for an initial RFC? Those have the strongest argument in favor of case=
-sensitivity given<br>how current autoloader implementations work - essenti=
ally the case-insensitivity doesn&#39;t properly work anyway in modern code=
.</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">...</blockq=
uote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">I&#39;d=C2=A0also ap=
preciate having a voting option for removing case-insensitivity right away,=
 as opposed to throwing E_STRICT/E_DEPRECATED. If we want to=C2=A0</blockqu=
ote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">change this, I person=
ally would rather drop it right away than start throwing E_STRICT warnings =
that would make the case-insensitive usage impossible anyway.</blockquote><=
div>It makes a lot of sense to me: a fairly simple change in the core and n=
o performance penalty. At the same time, a gradual approach will reduce the=
=C2=A0stress.<br></div><div><br></div><div>So the plan for 8.4 might be to =
just drop case insensitivity for class names and that&#39;s it... Let&#39;s=
 discuss that!</div><div><div><span class=3D"gmail_signature_prefix">-- <br=
></span>Best regards,<br><div dir=3D"ltr" class=3D"gmail_signature" data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr">Valentin Udaltsov<br><br></div=
></div></div></div></div></div></div></div></div>

--0000000000006cf903061a927158--