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?