On Thu, Feb 13, 2025 at 3:17 PM Tim Düsterhus <t...@bastelstu.be> wrote:
> Hi > > Am 2025-02-13 09:16, schrieb Jakob Givoni: > > Attributes were added as a structured replacement for docblock props > > and I > > don't like it when they affect how a program actually runs (as long as > > you're not using reflection). > > Excluding the `#[\Attribute]` attribute, PHP currently has 5 native > attributes and they all affect how the program runs. The initial > accepted Attribute RFC even lists several “behavior-affecting” > attributes in the “Use Cases” section: > https://wiki.php.net/rfc/attributes_v2#use_cases. It is probably fair to > say that use-cases like `#[\NoDiscard]` do not go against the vision > intended by the Attribute RFC. > > You could think of it as the PHP engine using Reflection internally to > do something differently. > I think all the native attributes so far, with the exception of #[\AllowDynamicProperties], only affect the program at compile-time, or by emitting errors. They don't affect the program otherwise by changing behavior, throwing exceptions etc. (As long as you don't use reflection, nor promote errors to exceptions.) AllowDynamicProperties is the only one that may change the program behavior at run-time by throwing an exception if the property is removed from a class while running PHP versions 9.0+. So this is not even a reality yet, since PHP 9 is not yet released. And I think it sets a bad precedent. Perhaps AllowDynamicProperties should have been a language construct instead. Or only fail at compile time. The original attributes RFC does mention "runtime behavior" in the introduction, but none of the use-cases proposed showcase it without using reflection or promoting errors to exceptions (as far as I can see). I don't mean to be rude and use your own words against you, but I found this quote in the "Why an attribute and not a keyword?" section of your #[\Override] RFC: > This RFC proposes an attribute instead of a keyword, because contrary to > other modifiers (e.g. visibility) that are part of the method signature, > the attribute does not affect behavior or compatibility for users that > further extend a given class and neither does it affect users that call the > method. It is purely an assistance to the author of a given class. (and I apologize if I misunderstand your intention or take it out of context completely), but I like the sentiment that "the attribute does not affect behavior or compatibility for users" and that it's part of the argument for an attribute instead of a keyword (language construct). I feel like #[NoDiscard] is getting dangerously close to being part of a method signature, especially if it throws exceptions at run-time (which I know it doesn't do in your RFC, so I'm less against it). I might be the only "purist" here, but just thought I would highlight that at least one php developer is hesitant with the direction attributes might be taking :-) Best, Jakob
