Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122233
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-119-ga8b98d1bd8-fm-20240108.001-ga8b98d1b
MIME-Version: 1.0
Message-ID: <3cbdc9bc-1d66-40b9-bc48-0506ba5e1977@app.fastmail.com>
In-Reply-To: 
 <pqNqnDTBZCeis6FA4j7mCDkENEfIpkN1-mUFziGcazrqbmp6GDQkFdlmOZVl0pUBdf_BJMCSPXz6Tqt19MCkUorZeXDCuC6fuAPBbxU4LzQ=@gpb.moe>
References: 
 <kii8EchCRNKJRI1IgoTQGYbxr2d0_BNN6dm4QrEFnWNaWLaH68cG-GioF5j6ebhIJv5wAVKdHojWk5XJqk9z_yL4cA0Fmb1KD0P19VrCiXU=@gpb.moe>
 <344c3e06-3822-4b20-9a6f-a58fb64929a7@app.fastmail.com>
 <pqNqnDTBZCeis6FA4j7mCDkENEfIpkN1-mUFziGcazrqbmp6GDQkFdlmOZVl0pUBdf_BJMCSPXz6Tqt19MCkUorZeXDCuC6fuAPBbxU4LzQ=@gpb.moe>
Date: Tue, 23 Jan 2024 16:37:10 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jan 23, 2024, at 2:18 AM, Gina P. Banyard wrote:
> On Monday, 22 January 2024 at 18:53, Larry Garfield 
> <larry@garfieldtech.com> wrote:
>> I am in support of this change. My only concern is timeline. This RFC would deprecate it in 8.4, and presumably support would be removed in 9.0. While we haven't discussed a timeline for 9.0, historically the pattern is every 5 years, which would put 9.0 after 8.4, which means only one year of deprecation notices for this change.
>
> There is no reason as to why 9.0 should come after 8.4, and I 
> fundamentally disagree with the logic that we somehow need to "plan" 
> deprecations around how much time we need to provide users to upgrade.
> To this day, I have never been provided any evidence that longer 
> deprecation times actually lead to users upgrading their code sooner 
> and not delay the inevitable.
> We were even told to shunt mass deprecation RFCs for 8.0 to 8.1, 
> effectively reducing how much time users have to upgrade for the sake 
> of simplifying the migration from 7.4 to 8.0.
>
> The idea for this RFC was floated around the time of PHP ***7***.4, but 
> this was deemed too soon due to cross version compatibility.
>
> Moreover, asking core developers to magically figure out all the 
> various ways PHP is bonkers or broken in a specific narrow time frame, 
> just so userland can have X version where the deprecation exists until 
> removal, is unreasonable.
> If this is the model that we should seek, then we should *completely* 
> move away from our current versioning system and do something more like 
> Python that provides 2 version where a feature is deprecated before 
> removing support.
> E.g. features deprecated in Python 3.9 were removed in Python 3.11.
>
> As such, I will not entertain this idea of timelines and when it is the 
> "right time" to deprecate something for it to be removed at the "right 
> time".
>
> If this is something people feel strongly, an RFC to change what our 
> versioning is and means should be done instead.
>
>> Given the massive amount of code that built up between 5.1 and 7.1, and 7.1 and today, I worry that a year won't be enough time for legacy code to clean up and it would be another "OMG you broke everything you evil Internals <expletive deleted>!" like the "undefined is now warning" changes in 8.0. (In both cases, well-written code any time from the past decade has no issue but well-written code is seemingly the minority.)
>
> I find this comparison disingenuous, fixing undefined variables is one, 
> if not two orders of magnitude harder than fixing this issue.
> Fixing implicit null to scalar types coercions for internal functions 
> causes way more havoc than this for legacy codebases, and yet we have 
> consistently maintained the rationale for the deprecation.
>
> While I do take into consideration the impact RFCs can have on existing 
> code bases, I consider having clear, easy, and comprehensible semantics 
> to be way more important than supporting some complicated and confusing 
> semantics for the sake of BC.
> There will always be code running on a completely outdated version of 
> PHP due to whatever reason.
> And refusing to fix the language and its semantics for the vast 
> majority of new code that is going to be written in it feels like a bad 
> decision to me.
> Especially if fixing it results in engine simplifications.
>
> We are our own project, and we need to make choices for the sake of the 
> health of the project, and this means removing stuff in a reasonable 
> timeline.
> I personally don't work on PHP to do legacy maintenance and keep 
> running it at all cost, if I did want to do this I'd be writing COBOL.
> I work on PHP because I believe it has a long future ahead of itself, 
> and that new people will learn it and use it.
> And forcing those people to need to learn, and remember bazillions of 
> gotchas really doesn't sound fair to them IMHO.

... I think you're grossly misreading my post.  I reiterate: I *support* this change.  I like it.  I want it to happen.  I am not proposing that we support broken old code indefinitely, nor have I ever done so.

But, 

>  I fundamentally disagree with the logic that we somehow need to "plan" 
> deprecations around how much time we need to provide users to upgrade.

I categorically disagree here.  PHP has a terrible reputation, even among its own boosters, for breaking people's stuff and making upgrades harder.  That is partially deserved, partially not.  (I've written in defense of Internals' improvements extensively.)  But as a project we need to consider both the practical and social impact of any breaking changes.

You assert that this is 1-2 orders of magnitude less impactful than undefined vars or null string params were.  I have no data on that off hand either way, so cannot confirm or deny that estimate.  (If you do, that would be very helpful.  No sarcasm, it really would.)  It is definitely more tooling-handleable, 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 tooling are the minority.

Even if this change is vastly smaller than previous flashpoints, my concern is it being large *enough* that it causes another rukus and more bad PR about "oh those PHP devs breaking everyone's code without any regard for we peons."  (cf: https://24daysindecember.net/2022/12/06/evolving-php/)  Whether or not that statement is true is irrelevant.  If that is the perception, it does harm to the PHP ecosystem.

Will this change be large "enough" to cause a fuss?  I don't know.  I fear it may be, but I don't know.  That's a worthwhile conversation to have, calmly.  But a longer deprecation period can help to reduce the fuss.  (Not eliminate, but that's not something we can expect.  Reduce is enough.)

There is indeed a related discussion around scheduling, deprecation timelines in general, etc.  As I said, I've tried to start that discussion in the past and was mostly ignored.

Maybe "all deprecations last for X releases, whatever the number" is a good 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 period for users to get up to speed on this change.  That's the entire point of deprecations.

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 scale where we have to think about such things.  Because every time we give someone a months long upgrade process, users migrate to Go, Node, etc.

We *do* need to clean up PHP's screwy edge cases, and I'm very glad that you've been working on that for so long.  But we also need to better manage that process to minimize the pain for downstream users, or we won't have downstream users.  Flippancy about them is counter-productive.

--Larry Garfield