Hi again,
Based on feedback to my last thread[1] that an RFC would be needed to allow
attributes on constants, I have just filed
https://wiki.php.net/rfc/attributes-on-constants and added it to the "Under
Discussion" section on the main RFC page.
I plan to open the vote in two weeks unless issues arise.
-Daniel
Hi
Based on feedback to my last thread[1] that an RFC would be needed to allow
attributes on constants, I have just filed
https://wiki.php.net/rfc/attributes-on-constants and added it to the "Under
Discussion" section on the main RFC page.
Thank you for your RFC. As you might have guessed from my comments on
the PR, I quite like the proposal to round off attributes. Nevertheless
any new syntax has quite a bit of an impact on tooling around PHP (see
also (3) below), so I'm curious if you already have any use cases
besides the #[\Deprecated] attribute that could be mentioned in the
RFC text?
Other than that, I have the following remarks to the RFC itself:
”New constant Attribute::TARGET_CONSTANT may conflict with subclasses
that define such a constant of their own.”
This is a non-issue, because the Attribute class is final.
”Extensions that validate the usage of their attributes and use
Attribute::TARGET_ALL may need to be updated.”
This is not just extensions, but also userland code that did not
anticipate any new attribute targets.
The “Backward Incompatible Changes” section should probably shortly
mention that this is new syntax and will need changes to IDEs, static
analysis tools and formatters. The second paragraph in
https://wiki.php.net/rfc/closures_in_const_expr#backward_incompatible_changes
might be a good example.
Best regards
Tim Düsterhus
Thank you for your RFC. As you might have guessed from my comments on
the PR, I quite like the proposal to round off attributes. Nevertheless
any new syntax has quite a bit of an impact on tooling around PHP (see
also (3) below), so I'm curious if you already have any use cases
besides the#[\Deprecated]attribute that could be mentioned in the
RFC text?
I don't have any other use cases at the moment - my primary motivation in
writing this feature was to allow deprecating constants. A few weeks ago I
gave a talk[1] where, among other things, I talked about how I was looking
forward to using the #[Deprecated] attribute, but that there was still room
for improvement since it could not be used on non-class constants. I then
figured: why not try to implement that support myself? And I eventually
figured it out.
This is a non-issue, because the Attribute class is final.
Fixed, thanks
This is not just extensions, but also userland code that did not
anticipate any new attribute targets.
Given that
- there isn't (as far as I know) a way to search for everything that has
an attribute - there isn't a current way to identify if a constant has an attribute
I didn't think there was anything to actually break for userland
attributes, but I've reworded the note to include userland attributes just
in case.
The “Backward Incompatible Changes” section should probably shortly
mention that this is new syntax and will need changes to IDEs, static
analysis tools and formatters. The second paragraph inhttps://wiki.php.net/rfc/closures_in_const_expr#backward_incompatible_changes
might be a good example.
Done
-Daniel
Hi
This is not just extensions, but also userland code that did not
anticipate any new attribute targets.Given that
- there isn't (as far as I know) a way to search for everything that has
an attribute- there isn't a current way to identify if a constant has an attribute
I didn't think there was anything to actually break for userland
attributes, but I've reworded the note to include userland attributes just
in case.
Here's an example of a userland library that collects attributes as a
“build time” step:
https://github.com/olvlvl/composer-attribute-collector
If that library is updated to understand attributes on constants and a
user applies a TARGET_ALL attribute on a constant, then this case would
apply.
Even if it ultimately is “just in case”, it’s nevertheless helpful to
spell out all possible caveats for the reader to make an informed
decision about the RFC. So thank you for the update :-)
With the updated version, I don't have any further comments about your
RFC text.
Best regards
Tim Düsterhus
On Sat, Nov 30, 2024 at 9:00 AM Daniel Scherzer daniel.e.scherzer@gmail.com
wrote:
Hi again,
Based on feedback to my last thread[1] that an RFC would be needed to
allow attributes on constants, I have just filed
https://wiki.php.net/rfc/attributes-on-constants and added it to the
"Under Discussion" section on the main RFC page.I plan to open the vote in two weeks unless issues arise.
-Daniel
It has now been just over 2 weeks since I filed the RFC, and over a week
since the last discussion point was resolved. Barring any surprises, I plan
to open the RFC for a vote tomorrow.
-Daniel