Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

[Stephen Reay]

Sent from my iPhone On 24 Jun 2024, at 23:43, Matthew Weier O'Phinney <mweierophin...@gmail.com> wrote:  On Mon, Jun 24, 2024 at 10:08 AM Nicolas Grekas <nicolas.grekas+...@gmail.com> wrote: Le mer. 5 juin 2024 à 10:18, Benjamin Außenhofer <kont...@beberlei.de> a écrit : On Wed, May 22, 2024 at 9:22 AM Benjamin Außenhofer <kont...@beberlei.de> wrote: The vote for the RFC #[\Deprecated] attribute is now open: https://wiki.php.net/rfc/deprecated_attribute Voting 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_attribute Voting 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'Phinney mweierophin...@gmail.com 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?