Re: Re: [RFC] [Vote] #[\Deprecated] attribute

From: Date: Tue, 25 Jun 2024 00:34:42 +0000
Subject: Re: Re: [RFC] [Vote] #[\Deprecated] attribute
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Sent from my iPhoneOn 24 Jun 2024, at 23:43, Matthew Weier O'Phinney
<[email protected]> wrote:On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas
<[email protected]> wrote:Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer
<[email protected]> a écrit :On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer
<[email protected]> wrote:The vote for the RFC #[\Deprecated] attribute is now open:https://wiki.php.net/rfc/deprecated_attributeVoting
will close on Wednesday 5th June, 08:00 GMT.

The #[\Deprecated] attribute has been accepted with 23 (Yes) to 6 (No) votes, 79%.The secondary vote
to include Deprecated::$since has also been accepted with 22 (Yes) to 1 (No) votes, 96%.Thank you to
everyone for voting!Tim will finalize the implementation PR now and work on its merge in the
upcoming days.

Hi Benjamin,The vote for the RFC #[\Deprecated] attribute is now open:https://wiki.php.net/rfc/deprecated_attributeVoting
will close on Wednesday 5th June, 08:00 GMT.

The #[\Deprecated] attribute has been accepted with 23 (Yes) to 6 (No) votes, 79%.The secondary vote
to include Deprecated::$since has also been accepted with 22 (Yes) to 1 (No) votes, 96%.Thank you to
everyone for voting!Tim will finalize the implementation PR now and work on its merge in the
upcoming days.

Since the vote passed, we're discussing how we might use the attribute in Symfony.2 things on
the topic:

1/ We're wondering about using it at the class level despite the missing
Attribute::TARGET_CLASS. ReflectionAttribute
 does allow reading attributes without checking these flags and we might
 leverage this capability to make our DebugClassLoader able to inspect 
those at the class level.Would you consider adding Attribute::TARGET_CLASS
 in 8.4 already? It would just make sense to me. We don't need the 
engine to do anything about deprecated classes ever since all we need in
 userland is a class-loader that checks for the attribute. Keeping the 
engine simpler and empowering userland with maximum flexiblity FTW. I'm 
up for a quick RFC if the consensus is this needs one.2/ About  the "since" parameter,
we're going to standardize around a package+version string, e.g.#[Deprecated(since:
"symfony/yaml v7.2"]I'm
 sharing this hoping this can spread outside of Symfony's boundary 
because I think this would be a very useful practice that'd allow 
building nice reporting tools.



Personally, I'd prefer the "since" format to mimic the notation that Composer uses on
the CLI when specifying a package with a constraint: "symfony/yaml:7.2.0". This can be
parsed easily, and won't suffer from having arbitrary spacing and version naming prefixes. 

(Still would prefer a "scheduledRemoval" field, as knowing when it was deprecated is far
less interesting than knowing when it will be removed. Yes, I can assume the next major version, but
what if it's major version + 1? What if a project allows removals during minor releases?
Knowing what version it will be removed in makes it far easier to understand what will happen when I
upgrade next.)

-- Matthew Weier O'[email protected]https://mwop.net/he/him
If you're marking a piece of code in  a project as deprecated, why does the deprecation notice
need to re-specify the package the code is in? Wouldn't a regular version string be sufficient?






Thread (21 messages)

« previous php.internals (#123799) next »