Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120183
Message-ID: <6cab1982-3323-25c4-b670-95798b176b09@bastelstu.be>
Date: Tue, 2 May 2023 19:05:43 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Dan Ackroyd <Danack@basereality.com>, =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=
 <kocsismate90@gmail.com>
Cc: Kamil Tekiela <tekiela246@gmail.com>,
 PHP Internals List <internals@lists.php.net>
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <CAGBsUrdFgHg7BPXCYiU0yfUtKWAUL3xGPoKmaOprgqs3NKsuEw@mail.gmail.com>
 <CAH5C8xULMjDtbiRGOZGhrbuF+EkprsznCasPzj7u6ykgRHDU3Q@mail.gmail.com>
 <CA+kxMuTRQLCaQhaORdktLMjbzf3XFz2d-q3sw0hD0K2VYCZosw@mail.gmail.com>
In-Reply-To: <CA+kxMuTRQLCaQhaORdktLMjbzf3XFz2d-q3sw0hD0K2VYCZosw@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/2/23 13:37, Dan Ackroyd wrote:
> For the functions that are having new separate methods added, not
> deprecating them immediately makes upgrading easier. When upgrading
> from one version of PHP to the next, it is best if you can run the
> same code on both versions, without any deprecation notices going off.

Agree here, I consider it a good thing if there's at least one version 
where both alternatives exist and are fully supported (i.e. without 
emitting a deprecation notice).

As an example, with PHP 8.3's addition of Randomizer::getFloat() and 
Randomizer::getBytesFromString() there are useful replacements for 
lcg_value() and uniqid() [1] respectively, but I'm intentionally not 
proposing deprecating either of them before whatever comes after PHP 8.3.

[1] The latter of which is likely one of the most misused functions in PHP.

> Would leaving the current versions in place and working actually cause
> any maintenance issues?
> 
> 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.

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.

I can also see how that would be useful for the planned deprecation of 
rand() and mt_rand(). Both of them have overloaded signatures, but will 
be part of the other deprecation RFC, as they also have a myriad of 
other issues that I consider to be worse than the signature. 
Unfortunately they are pretty ubiquitous, but luckily do not cause 
"internal" maintenance problems. So it would likely be feasible to keep 
them until 10, as long as they emit the deprecation notice to slowly nag 
developers away from them towards better alternatives.

Best regards
Tim Düsterhus