Re: #[Deprecated] Attribute
| From: | Benjamin Eberlei | Date: | Wed, 13 Jan 2021 12:46:54 +0000 |
| Subject: | Re: #[Deprecated] Attribute | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112869@lists.php.net to get a copy of this message | ||
On Wed, Jan 13, 2021 at 1:34 PM Marco Pivetta <ocramius@gmail.com> wrote:
> On Sun, Jan 10, 2021 at 2:48 AM G. P. B. <george.banyard@gmail.com> wrote:
>
>> Just to clarify this raises an E_DEPRECATED right?
>> Could it make sense to raise E_USER_DEPRECATED instead?
>>
>
> I hadn't checked this before, but as per George's message, this is
> worrying.
>
> I've been quite loud about it in the past, but static metadata definitions
> should really not lead to runtime side-effects, especially if not pure
> (error handling system tripped here).
>
> I'd be totally for a built-in
#[Deprecated] attribute if
> it did **NOT**
> have a runtime behavior, which is an absolute no-go from my PoV.
>
> This stuff is easily introspectible via tools like phpstan, psalm, phan,
> and does not need to lead to more problematic runtime issues.
>
I get where you are coming from, but side-effect based notices/deprecations
is just the way PHP works at the moment and as such this existing mechanism
should be used and extended.
I do have (vague) plans to tackle alternative ways to process
notices/deprecations in the future, but this is independent from that and
#[Deprecated] would automatically tie into a change of this kind.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>