On Mon, Jun 24, 2024, 7:35 PM Stephen Reay <php-li...@koalephant.com> wrote:
> > 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.) > > > 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? > Because the consumer of the code might not know what package supplied it, particularly if multiple packages share a namespace. > >
