Re: #[Deprecated] Attribute

From: 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 [email protected] to get a copy of this message
On Wed, Jan 13, 2021 at 1:34 PM Marco Pivetta <[email protected]> wrote:

> On Sun, Jan 10, 2021 at 2:48 AM G. P. B. <[email protected]> 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/
>
>


Thread (16 messages)

« previous php.internals (#112869) next »