On 24 April 2024 18:18:28 BST, Jorg Sowa <jorg.s...@gmail.com> wrote:
> What about setting this parameter vaguely as the boolean we can pass?
> ...
> #[Deprecated(since: $packageVersion > 5.5)]
> #[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 reflection 
doesn't give any access to the source code or AST of how the attribute was 
written, so this would just end up with a meaningless "$since = true", and some 
source code that might as well be a comment. 

To be honest, I'm not really sure what I'd do with the information in a "since" 
field even if it was there. If you were running PHP 7.4, what difference would 
it make to know that create_function was deprecated in 7.2, rather than in 7.1 
or 7.3? The two relevant facts are when the suggested replacement was 
introduced (in case you need to support multiple versions); and what is the 
soonest that the deprecated feature will be removed. The second in particular 
is something I would like every deprecation message to include, rather than the 
vague "may be removed in a future version".

I found this discussion of "since" in Rust's implementation, but don't find the 
arguments in favour particularly compelling: 
https://github.com/rust-lang/rfcs/pull/1270#issuecomment-138043714


Of interest, that discussion also linked to a related feature in Java, which 
could perhaps be added to a list in the RFC alongside the Rust and JetBrains 
ones already mentioned: https://openjdk.org/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. The Java proposal states this nicely: 

> 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. All of these topics require
> discussion and are thus better suited for textual
> documentation.

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. Both it and "since" are explicitly marked 
"applicable only for PhpStorm stubs".

Regards,
Rowan Tommins
[IMSoP]

Reply via email to