Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120184
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-386-g2404815117-fm-20230425.001-g24048151
Mime-Version: 1.0
Message-ID: <dc90b3bf-6989-4117-be7d-11a9df0c39ba@app.fastmail.com>
In-Reply-To: <6cab1982-3323-25c4-b670-95798b176b09@bastelstu.be>
References: 
 <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <CAGBsUrdFgHg7BPXCYiU0yfUtKWAUL3xGPoKmaOprgqs3NKsuEw@mail.gmail.com>
 <CAH5C8xULMjDtbiRGOZGhrbuF+EkprsznCasPzj7u6ykgRHDU3Q@mail.gmail.com>
 <CA+kxMuTRQLCaQhaORdktLMjbzf3XFz2d-q3sw0hD0K2VYCZosw@mail.gmail.com>
 <6cab1982-3323-25c4-b670-95798b176b09@bastelstu.be>
Date: Tue, 02 May 2023 19:06:44 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, May 2, 2023, at 5:05 PM, Tim D=C3=BCsterhus 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=20
> where both alternatives exist and are fully supported (i.e. without=20
> emitting a deprecation notice).
>
> As an example, with PHP 8.3's addition of Randomizer::getFloat() and=20
> Randomizer::getBytesFromString() there are useful replacements for=20
> lcg_value() and uniqid() [1] respectively, but I'm intentionally not=20
> 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?
>>=20
>> 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=20
> must be removed in major X+1? Otherwise deprecating with 8.3 and=20
> removing in 10 would be an option that could be evaluated when it's ti=
me=20
> 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=20
> rand() and mt_rand(). Both of them have overloaded signatures, but wil=
l=20
> be part of the other deprecation RFC, as they also have a myriad of=20
> other issues that I consider to be worse than the signature.=20
> Unfortunately they are pretty ubiquitous, but luckily do not cause=20
> "internal" maintenance problems. So it would likely be feasible to kee=
p=20
> them until 10, as long as they emit the deprecation notice to slowly n=
ag=20
> developers away from them towards better alternatives.
>
> Best regards
> Tim D=C3=BCsterhus

Given past pushback on changes that we've gotten, a low-cost/no-cost lon=
g deprecation period seems like it would be very appreciated.

I've actually been considering proposing an RFC to mandate a minimum tim=
e length between deprecation and actual removal/change for that reason.

--Larry Garfield