Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120231
Message-ID: <9ab0173f-a6f2-66f6-3ab3-d5f0c44feb05@bastelstu.be>
Date: Thu, 11 May 2023 11:36:37 +0200
MIME-Version: 1.0
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>,
 Larry Garfield <larry@garfieldtech.com>
Cc: 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>
Content-Language: en-US
In-Reply-To: <CAH5C8xVJPXx8Mk5WViOiqBe-094zTbtSO6pkZGx2BeGKbaXVoA@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 00:10, Máté Kocsis wrote:
> If not, then we could just move really slowly on deprecating them. We
>> could deprecate them at some point in the 9.x release cycle and remove
>> them in 10.0.
> 
> 
> Although I would love to get rid of as many overloaded signatures as
> possible due to the above mentioned fact,
> I admit that there might be some signatures which other internals would
> prefer to phase out slower than me. So
> thanks for the idea! Now, the individual votes in the RFC contain 2 options
> for removing a signature: a shorter path (deprecation
> in PHP 8.4, removal in PHP 9.0) and a longer one (deprecation in PHP 9.0
> and removal in PHP 10.0).
> 

I believe this vote format ("three options") is not really compatible 
with the voting rules (https://wiki.php.net/rfc/voting).

For example it's not entirely clear what would happen here:

5 votes to deprecate in 8.3 / remove 9.0
4 votes to deprecate in 9.0 / remove 10.0
4 votes to not deprecate.

Neither option has a 2/3 majority over any other option. The two 
deprecation options together have a 2/3 majority over not deprecating, 
which might indicate that a deprecation should happen. But in which 
version? This would likely require ranked choice voting which feels 
complex for something that should be a simple vote.

I've had a similar issue with my "Improve unserialize() error handling 
RFC" (https://externals.io/message/118566) and opted to make an 
executive decision as the RFC author and not offer one of the possible 
version targets to avoid that problem entirely.

----------------------

Repeating my previous question:

> Does it necessarily follow that a function that is deprecated in major X 
> must be removed in major X+1? Otherwise deprecating with 8.3 and 
> removing in 10 would be an option that could be evaluated when it's time 
> for 9 and the migration did not yet "sufficiently" happen in userland code.

Would it be an option to just deprecate everything in PHP 8.3 and defer 
the vote for the removal target version to a later date? This would give 
users the deprecation notice as early as possible and also gives them 
appropriate time to migrate if migration for a specific set of functions 
is (much) slower than others. 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.

Best regards
Tim Düsterhus