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

On Tue, May 2, 2023, at 5:05 PM, Tim Düsterhus wrote: > 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 Given past pushback on changes that we've gotten, a low-cost/no-cost long deprecation period seems like it would be very appreciated. I've actually been considering proposing an RFC to mandate a minimum time length between deprecation and actual removal/change for that reason. --Larry Garfield