Hi Sara
On Tue, Dec 22, 2020 at 12:35 PM Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:It would be great to allow adding this attribute on classes. What
about
allowing it right now and not bind it to any runtime side-effect? That
would allow static analyzers to do their job. Same for consts and
properties by the way.Also, it would be very useful to add named parameters to the
attribute,
namely: "package" (the name of the package that declares the
deprecation)
and "version" (the version of that package that introduced the
deprecation), next to the message.This is critical info when building reports of deprecations.
You could do that now with a polyfill from userspace. If the annotation
need not have an effect, then it's just any other userspace
implementation.The difference is that PHP core has the ability to force standarization.
There's already JetBrains' implementation of #[Deprecated], which Psalm
and
PhpStan also support, but it's not a real standard. Maybe the FIG would
one
day step in to decide these kinds of things, but the reality is that
many
major frameworks don't follow FIG as closely as they used to. I think
there's value in adding attributes in the core, with the goal only being
static analysis. It'll allow for consistency and that's a valuable
thing.I want to keep #[Deprecated] on other elements than functions / methods
out
of this RFC, because they require entirely different implementation
approaches.We identified in the PR already that this should at some point be
standardized in core, because internal attributes will currently not be
able to support extension through inheritance by userland for
implementation reasons.My next RFC update will reflect this future scope.
Last night, I identified a need for
#[Deprecated]on a userland class in
one of my libraries, but I had to settle on@deprecatedfor the widest
range of compatibility.Has there been anymore thought on putting together an implementation for
this? I’m happy to draft an RFC if someone is able to help with the
implementation. I don’t understand the complexities around the
implementation, but is this something that could make it into 8.5, provided
an RFC vote passes?Cheers,
Ben
I have needed this as well at work for a shared library and i'm sure many
library authors would use it too.
Current IDE's like jetbrains has support for #[Deprecated($reason,
$replacement)] which will throw warning in the IDE,
see their implementation here:
https://github.com/JetBrains/phpstorm-attributes?tab=readme-ov-file#deprecated
If this could be supported at a language level, package authors, frameworks
and internal company libraries would benefit from it.
I see no reason why anyone would be against the idea, other than pure chaos
evil.