Re: [RFC] [Discussion] Deprecate functions with overloaded signatures

From: Date: Thu, 11 May 2023 17:06:44 +0000
Subject: Re: [RFC] [Discussion] Deprecate functions with overloaded signatures
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-120235@lists.php.net to get a copy of this message
Hi On 5/11/23 18:58, Dan Ackroyd wrote:
On Thu, 11 May 2023 at 10:36, Tim Düsterhus <tim@bastelstu.be> wrote:
Would it be an option to just deprecate everything in PHP 8.3
As I said before, having at least one version where the new versions of the functions are available, and the old versions aren't giving deprecation notices, is the 'cleanest' way of refactoring functions.
Right. Replace "8.3" by "the first version after the replacement is available" in my previous email. My main question was …
Deprecation notices only deliver their value when the old versions of the functions are removed, and before then are a cost.
It doesn't really feel right to decide on a deprecation for 9.0 / removal for 10.0 at the current time, but deprecation in 8.3 + removal when it's ready seems to be okay.
I think I don't understand your concern. If a problem is discovered with a planned removal of something, people on this project are mostly reasonable*, and a small RFC to adjust to the new circumstances would be very likely to pass.
… the following: I wanted to know if "Deprecate in 8.x + not remove in 9.0, but only remove in 10.x or 11.x" would be an option, because I feel that it is more useful than "If we deprecate in 8.x then we MUST remove in 9.0, that's why we're already making deprecation plans for 9.x, so we are able to remove in 10.0" All the discussion so far had "Deprecate in x.y and remove in x+1.0", but not "Deprecate in x.y and remove in x+n.0 with n > 1". Best regards Tim Düsterhus

« previous php.internals (#120235) next »