Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122234
Date: Tue, 23 Jan 2024 18:16:26 +0000
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Message-ID: <2N2mAsgNzhqdHNUFHztZe9qaa7wAQNM7foB71qbCikxrrD9yHVdTXklGDRH7zHq2pucR0CKJVqTMdqRJFLF6J5wovkebG7ropbA_j4FbpQ8=@gpb.moe>
In-Reply-To: <3cbdc9bc-1d66-40b9-bc48-0506ba5e1977@app.fastmail.com>
References: <kii8EchCRNKJRI1IgoTQGYbxr2d0_BNN6dm4QrEFnWNaWLaH68cG-GioF5j6ebhIJv5wAVKdHojWk5XJqk9z_yL4cA0Fmb1KD0P19VrCiXU=@gpb.moe> <344c3e06-3822-4b20-9a6f-a58fb64929a7@app.fastmail.com> <pqNqnDTBZCeis6FA4j7mCDkENEfIpkN1-mUFziGcazrqbmp6GDQkFdlmOZVl0pUBdf_BJMCSPXz6Tqt19MCkUorZeXDCuC6fuAPBbxU4LzQ=@gpb.moe> <3cbdc9bc-1d66-40b9-bc48-0506ba5e1977@app.fastmail.com>
Feedback-ID: 96993444:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
From: internals@gpb.moe ("Gina P. Banyard")


On Tuesday, 23 January 2024 at 16:37, Larry Garfield <larry@garfieldtech.co=
m> wrote:

> On Tue, Jan 23, 2024, at 2:18 AM, Gina P. Banyard wrote:
>=20
> > I fundamentally disagree with the logic that we somehow need to "plan"
> > deprecations around how much time we need to provide users to upgrade.
>=20
>=20
> I categorically disagree here. PHP has a terrible reputation, even among =
its own boosters, for breaking people's stuff and making upgrades harder. T=
hat is partially deserved, partially not. (I've written in defense of Inter=
nals' improvements extensively.) But as a project we need to consider both =
the practical and social impact of any breaking changes.

PHP has a terrible reputation because it didn't try to fix any of its crap =
for years.
PHP has a terrible reputation because it added random ill designed stuff at=
 random prior to the RFC process.
PHP has a terrible reputation because it has insane bonkers semantics.
PHP has a terrible reputation because its image is stuck in 2005.
PHP has a terrible reputation because of projects written in PHP having "ba=
d" codebases.
etc. etc.

I've stopped counting how many times I've been sent "PHP: a fractal of bad =
design" [1], how many times have people have brought up to me the fact PHP =
is the only language they know that undeprecated something (for reference i=
s_a() in 5.1), and other countless stuff that I need to hear semi often.

Internals is blamed for making upgrades hard, the life of library maintaine=
rs hell, and everything that could be assigned blame to internals.
But I have never seen internals tell userland to promote deprecations to ex=
ceptions, userland came up with this, and uses this as a tool to harass lib=
rary maintainers.

Maybe I'm just weird, but I don't actually care that projects still use PHP=
 7, 5, 4, or 3. Because there will always be such projects, and basing my d=
ecisions on those makes no sense to me.
It helps that I also hear people that are satisfied and happy with the lang=
uage being tighter, but those are rarely said publicly, because there is no=
 need to complain online when one has nothing to complain about.

And again, I frankly don't believe that providing 2, 3, 5, 10 years of depr=
ecation before a removal is effectively different from providing 1 year.
People will either fix it immediately, or leave it until the end of time an=
d still make a fuss about it.

>=20
> You assert that this is 1-2 orders of magnitude less impactful than undef=
ined vars or null string params were. I have no data on that off hand eithe=
r way, so cannot confirm or deny that estimate. (If you do, that would be v=
ery helpful. No sarcasm, it really would.) It is definitely more tooling-ha=
ndleable, and it sounds like there's ample existing tooling for it, so that=
's great and will help, but as we've noted many times, people using good to=
oling are the minority.

I don't need data to know this change is less impactful.
Undefined vars requires either tracking the source of the first usage, or g=
uarding every usage with a null coalesce operator.
Implicit coercions require the same thing, either tracking the source, guar=
ding every usage, or doing the worst option to just chug an explicit cast i=
n front.
And both of these things can happen countless times all over the code base,=
 thus flooding logs.

Compared to this change, which requires changing the unique definition of t=
he offending function/method signature.

I cannot comprehend how at the same time we need to treat users as capable,=
 intelligent, knowledge people when introducing features.
And at the same time consider them to be incompetent, and lacking skills to=
 use tooling.

For this deprecation the tooling _already_ exists, if people don't want to =
use it, why? If people don't know about it, why? If people don't trust it, =
why?
This is different from a bunch of other changes where any tooling would be =
brand new.

>=20
> There is indeed a related discussion around scheduling, deprecation timel=
ines in general, etc. As I said, I've tried to start that discussion in the=
 past and was mostly ignored.
>=20
> Maybe "all deprecations last for X releases, whatever the number" is a go=
od policy to have; I don't know. Deciding now that there will be an 8.5 and=
 then a 9.0 is also a viable option, which will also give 2 years grace per=
iod for users to get up to speed on this change. That's the entire point of=
 deprecations.

Maybe because fixed major release cycles for a programming language is just=
 a bad idea?
Because what does a "major" release entail for a programming language?
And if someone wants to deprecate something in 8.5 what do we tell them? No=
?
PHP is an open source project, people come and go, and start contributing a=
t different times. And telling someone nah sorry you should have started co=
ntributing 3 years ago to be able to make this change is extremely toxic IM=
HO?
(c.f. the debacle from last year)
And when thinking of those sorts of policies, the health of the project and=
 its contributors must be front and centre.
If there is no one to maintain, or that wants to maintain PHP, it doesn't m=
atter that there are downstream users or not.

Yes, PHP has the Foundation now, and yes they pay me and others to work on =
PHP, but I don't think its mere existence means that the project is still n=
ot at risk.
And anything that leads to friction for new people to contribute, or existi=
ng contributors to burn out, is just bad.
One should be able to improve PHP the moment one starts contributing, regar=
dless of the nature of said improvement.

>=20
> What I do not think is a good approach is "meh, we'll deprecate whenever,=
 and remove whenever, we'll tell you when we get there." That's not helpful=
 to our downstream users, without whom there is no project. PHP is at a sca=
le where we have to think about such things. Because every time we give som=
eone a months long upgrade process, users migrate to Go, Node, etc.

Implying something could be removed whenever really feels like you are sayi=
ng we could just remove stuff in 8.4.
Not having a date for PHP 9 is not equivalent to something being removed wh=
enever.

Again, maybe I am just weird, but if the code is in such a state that peopl=
e rewrite their code, regardless of in another language or not, I see this =
as a win.
People already migrate to other languages because they don't think PHP is g=
ood enough.

Also, am I the only one remembering people wanting a PHP 7.5 with no featur=
es and just deprecations or what? This clearly gave me the impression peopl=
e wanted to get rid of problematic baggage, instead of what has been recent=
ly portrayed.
Probably, because for once, it was the other crowd shouting into internals?


Best regards,

Gina P. Banyard

[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/