Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120241
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-415-gf2b17fe6c3-fm-20230503.001-gf2b17fe6
Mime-Version: 1.0
Message-ID: <897f89d9-9d02-4f15-a81e-a8355d097a5f@app.fastmail.com>
In-Reply-To: <D222D279-03C2-413A-A65A-67EA96EFBF88@gmail.com>
References: 
 <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <ffa8138a-f1b6-3926-bc2f-558ffca344b0@gmail.com>
 <CAH5C8xXhCkZt7bBs7YcjMBRYM5ggu7W47huCCbVwb2-q_zFnBA@mail.gmail.com>
 <e3eba528-a015-48be-ba8e-fa71d512aa33@app.fastmail.com>
 <CAH5C8xVJPXx8Mk5WViOiqBe-094zTbtSO6pkZGx2BeGKbaXVoA@mail.gmail.com>
 <9ab0173f-a6f2-66f6-3ab3-d5f0c44feb05@bastelstu.be>
 <CA+kxMuT_DsqqH6-pq+P7ZjddEpCetHhYQvuDkAd4_oNSh7ePpA@mail.gmail.com>
 <D222D279-03C2-413A-A65A-67EA96EFBF88@gmail.com>
Date: Fri, 12 May 2023 14:29:10 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, May 12, 2023, at 6:52 AM, Rowan Tommins wrote:

> I think it's actually very likely that voters would want to express 
> "deprecate, but do not remove before 10.0". Treating those votes as 
> "generally in favour, so enough to approve removal in 9.0" doesn't seem 
> appropriate.
>
> The other way around - "deprecate, but do not remove later than 9.0" - 
> seems less likely. I also don't see any reason to delay the deprecation 
> - the whole point of the longer period is to give people more notice.
>
> So I would suggest rewording the options slightly:
>
> a) Deprecate in 8.3, remove in either 9.0 or 10.0
> b) Deprecate in 8.3, remove in 10.0
> c) Do not deprecate
>
> Now if the votes are a:5, b:4, c:4, we can say:
>
> - 9 people voted for deprecation in 8.3, vs 4 against
> - only 5 voted for removal in 9.0, vs 8 against
> - 9 voted for removal in 10.0, vs 4 against
>
> So we conclude that we should deprecate in 8.3, and remove in 10.0
>
>
> The suggestion to narrow it down to a yes/no proposal in the discussion 
> phase is probably even better, though.

Personally I'm on team "add new functions now, deprecate old ones in 9, remove old ones in 10."  

1. As noted, it gives people a clean window in which to use the old or new ones without getting a deprecation warning, and without cutting off support for old but still supported PHP versions.
2. It gives people ample time to fix their code.  (Around 7-8 years.)
3. Perhaps most importantly, it's a good-faith gesture to the people who have objected (validly, if sometimes impolitely and crudely) to shorter deprecation periods in the past.  There is definitely a relationship building to be done with the broader user-space community, and offering a very wide grace period is a good way to help with that.

That these particular functions and uses are quite rare doesn't really change any of that; if anything it strengthens it, that we're willing to be graceful about it even in cases where we could probably get away with not being so.

--Larry Garfield