Hi Sara

> On 22 Dec 2020, at 19:54, Sara Golemon <poll...@php.net> wrote:
> 
> On Tue, Dec 22, 2020 at 12:35 PM Nicolas Grekas <
> nicolas.grekas+...@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.

> 
> -Sara


Kind regards
Brent
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to