Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110057
MIME-Version: 1.0
References: <CAEPJdum26d_x6z2K4BFvRBXhNh8qQrh0tTE7wXzsfV7rwgm9Lg@mail.gmail.com>
 <CANaX5ncyFO9o7_z2n_ZsqVAzM7Qg6kxBWLqShWKS+1o=o6Fe+Q@mail.gmail.com>
In-Reply-To: <CANaX5ncyFO9o7_z2n_ZsqVAzM7Qg6kxBWLqShWKS+1o=o6Fe+Q@mail.gmail.com>
Date: Thu, 7 May 2020 10:18:12 +0200
Message-ID: <CAEPJdu=MCYM5o-B96f6P+T7rCP+LqD5JCd=7M4SZ97MfxXoOBg@mail.gmail.com>
To: Davey Shafik <davey@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002f666305a50a86f5"
Subject: Re: [PHP-DEV] [RFC] <<Deprecated>> Attribute
From: kontakt@beberlei.de (Benjamin Eberlei)

--0000000000002f666305a50a86f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 7, 2020 at 10:10 AM Davey Shafik <davey@php.net> wrote:

>
>
> On Thu, May 7, 2020 at 00:22 Benjamin Eberlei <kontakt@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 R=
FC
>> 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 wel=
l
>> - 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 onl=
y
> 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 =3D null, $bar =3D null) { }
>
> It's not great IMO. Having said that, I don't think this bit is really
> necessary =E2=80=94 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 introduci=
ng
> 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).

--0000000000002f666305a50a86f5--