Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120235
Message-ID: <dcf167a6-95e0-480a-297c-e9aae2a4354c@bastelstu.be>
Date: Thu, 11 May 2023 19:06:44 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Dan Ackroyd <Danack@basereality.com>
Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>,
 Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
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+kxMuRUgodOY622YDZEW3NJJab1DYCijA1_xNnRMjtt8ab39Q@mail.gmail.com>
In-Reply-To: <CA+kxMuRUgodOY622YDZEW3NJJab1DYCijA1_xNnRMjtt8ab39Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

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