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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php