Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123206
Feedback-ID: id5114917:Fastmail
Date: Thu, 25 Apr 2024 07:44:10 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Discussion] #[\Deprecated] attribute again v1.3
User-Agent: K-9 Mail for Android
In-Reply-To: <CAPTD5yHzg-Rm+2sFqSbzj4pyU40MMg_4tMME88W_Mqf4yKK_yw@mail.gmail.com>
References: <CAEPJdumvJNQ+JZ3wkLP-Q2O0y57g=W_hHFkuvOKMVJqqraKCzw@mail.gmail.com> <CANS-=pdE8GX8-qpn3iZ_A7ZDKRW27mUhwA14rAtJmZOyZWa1-w@mail.gmail.com> <CAEPJdukkD_3PhP5mHogX4-LNNGFbRPiwU0zvgAvK9uaAHdy0yA@mail.gmail.com> <CAPTD5yHzg-Rm+2sFqSbzj4pyU40MMg_4tMME88W_Mqf4yKK_yw@mail.gmail.com>
Message-ID: <5814C522-CD23-4194-A344-1B57CC0A2511@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 24 April 2024 18:18:28 BST, Jorg Sowa <jorg=2Esowa@gmail=2Ecom> wrote:
> What about setting this parameter vaguely as the boolean we can pass?
> =2E=2E=2E
> #[Deprecated(since: $packageVersion > 5=2E5)]
> #[Deprecated(since: PHP_VERSION_ID > 80100)]
> #[Deprecated(since: date("Y-m-d") > "2024-01-21")]


Even if these expressions were legal, as far as I know, standard reflectio=
n doesn't give any access to the source code or AST of how the attribute wa=
s written, so this would just end up with a meaningless "$since =3D true", =
and some source code that might as well be a comment=2E=20

To be honest, I'm not really sure what I'd do with the information in a "s=
ince" field even if it was there=2E If you were running PHP 7=2E4, what dif=
ference would it make to know that create_function was deprecated in 7=2E2,=
 rather than in 7=2E1 or 7=2E3? The two relevant facts are when the suggest=
ed replacement was introduced (in case you need to support multiple version=
s); and what is the soonest that the deprecated feature will be removed=2E =
The second in particular is something I would like every deprecation messag=
e to include, rather than the vague "may be removed in a future version"=2E

I found this discussion of "since" in Rust's implementation, but don't fin=
d the arguments in favour particularly compelling: https://github=2Ecom/rus=
t-lang/rfcs/pull/1270#issuecomment-138043714


Of interest, that discussion also linked to a related feature in Java, whi=
ch could perhaps be added to a list in the RFC alongside the Rust and JetBr=
ains ones already mentioned: https://openjdk=2Eorg/jeps/277

It's interesting to note, for instance, that both Java and Rust designers =
considered a specific "replacement" field, but decided that it was unlikely=
 to be useful in practice=2E The Java proposal states this nicely:=20

> In practice, there is never a drop-in replacement API for
> any deprecated API; there are always tradeoffs and
> design considerations, or choices to be made among
> several possible replacements=2E All of these topics require
> discussion and are thus better suited for textual
> documentation=2E

The JetBrains attribute *does* include a "replacement" argument, but it's =
heavily tied into a specific use case: it contains a template used for code=
 transformation in the IDE=2E Both it and "since" are explicitly marked "ap=
plicable only for PhpStorm stubs"=2E

Regards,
Rowan Tommins
[IMSoP]