On Thu, May 7, 2020 at 10:10 AM Davey Shafik <da...@php.net> wrote:

>
>
> On Thu, May 7, 2020 at 00:22 Benjamin Eberlei <kont...@beberlei.de> wrote:
>
>> Hi everyone,
>>
>> The attributes RFC specifically looked into the use of attributes at the
>> engine/compiler level.
>>
>> To have a showcase of this with the 8.0 release I want to propose this RFC
>> for a <<Deprecated>> attribute:
>>
>> https://wiki.php.net/rfc/deprecated_attribute
>>
>> <<Deprecated>> is the most obvious engine attribute to add at the
>> beginning
>> in my opinion, as
>>
>> - all other languages with Attributes/Annotations support have it as well
>> - its effects are quite obvious to understand, as such offer a good
>> example
>> and intro to attributes
>> - with potential property/class constant deprecation it adds something
>> that
>> was not possible in userland before.
>>
>> Let me know what you think!
>>
>> greetings
>> Benjamin
>
>
> Hi Benjamin,
>
> Two things:
>
> 1) as a matter of course, I prefer things that can be done in userland be
> done in userland unless there is a clear performance or other win. This
> doesn't qualify for me, except that it would be possible to use the same
> mechanism in core, but that really only gives us the ability to reason
> around depredations with reflection and I don't see much value in that. I'm
> not entirely convinced that a PSR and a defecto implementation isn't a
> better solution here. This isn't a show-stopper though.
>

Can you clarify a bit your argument "ability to reason around deprecations
only with reflection"?

At the moment we can only reason about deprecations by using both
token_get_all and finding that a method calls trigger_error
E_USER_DEPRECATED and by looking at the doc comments (via reflection) for
"@deprecated". My argument for this attribute is that it leads to both a
documentation based deprecation, and a runtime declaration at the same
time. It is a better result than what we can do in userland in my opinion.


>
> 2) AFAICT you cannot add an attribute to a function argument, and the only
> way I can see to resolve that is to add a "DeprecatedArgument" attribute
> applied to the function that takes the name as the first arg (and the
> message as the second). Now you're looking at:
>
> <<DeprecatedArgument('foo')>>
> <<DeprecatedArgument('bar')>>
> function bat($foo = null, $bar = null) { }
>
> It's not great IMO. Having said that, I don't think this bit is really
> necessary — unlike the other suggested uses, an argument isn't an isolated
> thing, so much as part of the function signature as a whole and removing
> arguments is better done by deprecating the entire function and introducing
> a new version with a different name. So maybe we just don't need this?
>

It is possible to add attributes to parameters. This was added as an
improvement during the Attributes RFC (it was not possible in the first
draft).

Reply via email to