Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123575
Content-Type: multipart/signed;
	boundary="Apple-Mail=_D242B23F-96BB-4EE5-BC6B-9A722B6900E4";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: [PHP-DEV] Revisiting case-sensitivity in PHP
In-Reply-To: <CAPyeZ4O2rK+2ApuE-YLc7j_Z2LcT29yHcLYXvB0oGs-D_zTSag@mail.gmail.com>
Date: Mon, 10 Jun 2024 23:36:26 -0400
Cc: php internals <internals@lists.php.net>
Message-ID: <D0449280-7113-48A3-979B-7995051B622C@php.net>
References: <CAPyeZ4O2rK+2ApuE-YLc7j_Z2LcT29yHcLYXvB0oGs-D_zTSag@mail.gmail.com>
To: Valentin Udaltsov <udaltsov.valentin@gmail.com>
From: ramsey@php.net (Ben Ramsey)


--Apple-Mail=_D242B23F-96BB-4EE5-BC6B-9A722B6900E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jun 10, 2024, at 20:35, Valentin Udaltsov =
<udaltsov.valentin@gmail.com> wrote:
>=20
> Hi, internals!
>=20
> 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.
>=20
> What is case-sensitive in PHP 8.3:
> - variables
> - constants (all since =
https://wiki.php.net/rfc/case_insensitive_constant_deprecation)
> - class constants
> - properties
>=20
> What is case-insensitive in PHP 8.3:
> - namespaces
> - functions
> - classes (including self, parent and static relative class types)
> - methods (including the magic ones)
>=20
> 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=3DAll%20class%20names%20MUST%2=
0be%20referenced%20in%20a%20case%2Dsensitive%20fashion)
>=20
> Cons:
> 1. pain for users, obviously
> 2. a backward compatibility layer might be difficult to implement =
and/or have a performance penalty
>=20
> 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)
>=20
> 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.
>=20
> 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=E2=80=99m 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


--Apple-Mail=_D242B23F-96BB-4EE5-BC6B-9A722B6900E4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmZnxjoACgkQ+cOdwLlp
hUR+lQ//bOmJLzA79DOgXQLGQSfMzRKt+hUaP7FJjXf9LKXs06Gf8PNZLjKaCBKQ
ekbu16kPWf5VUfYT0QCLgDLxkJ0sQh2hjVCYElH21Uuj8RAfnEM1tWnqM+pCeSBI
PJiGa0nLvSj/0QbPT7GSLTtIi/5+1tG9R44LER5Udok6cetTJlGdpoOQ8R/yM/Rr
2wHsTkhlbsrIMUpczKiwXL3gx14LV/0UClpnsyvQFu9jf+MHU2wvAA7nPK0gZ6SY
16sjWfBMd6tDpxPQYdIr8BXRRZnlZ8pEv8FYwitVRwaqJW4wDp1Tm7tQ7joG3vY4
K2iarm9CqLZs3K1MIE4zj75aqO9eQvZTwA+LAfiAJVPkHr9zdC8OZqLtYyXPn+M1
QX18gcHoxPKASk0HkS849lGXFBEJQj8rntpMQahC+KhdYIK7B9tl6uChBilVkWMq
YTMLUn1XPxTfsLCAOb6jQI7eM9kXpVOq7/iul9HOevA1MeAsaKIy14OEp35b0itH
lr0CMf/FK9C/0qvcE0ntI5neSdWlsCjZy1xJU+72CbXFB3E1XMdTND6CIw1DGBP2
Oicv29r+/+cNRqIN3jV3LakouD0EBfKaZUzV5m0plCMfBMUsrxsa2Eh3E6traC6u
AIm/ThQjhdmtT5uKJU8aLTNSZcObOIy9oc55vfO4ratECTp83Ok=
=GWuT
-----END PGP SIGNATURE-----

--Apple-Mail=_D242B23F-96BB-4EE5-BC6B-9A722B6900E4--