On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei <kont...@beberlei.de> wrote:
> https://wiki.php.net/rfc/shorter_attribute_syntax_change > > I have updated the RFC one last time with as much of the feedback > as possible: > > - a section about comparing to complexity of type definitions > - removal of the machine reading section as too narrow and > ultimately not that important as downstream libraries just have to > deal with any of it > - some more nuances in forward compatibility pro/cons section of #[] > - smaller corrections and improvements. > > I don't think something major is missing now. Hi Benjamin, Thanks for the updates. I just have a few more thoughts on aspects that haven't been mentioned before: 1. The **Attributes are not like Modifiers** section makes an argument that having an end delimiter "groups docblock comment and attributes into two similarly shaped syntax blocks that prefix the declaration increasing familiarity." In my own (admittedly subjective) opinion, an end delimiter on attributes actually increases confusion when there is also a docblock. To reuse the example from the RFC: /** * A comment describing things. * * @psalm-suppress SomeRule */ #[ ORM\Entity(), ORM\Table("baz") ] final class Something { } Because the attribute group has its own start and end delimiters, it almost looks like the doc comment applies to the attribute block rather than the class. With the `@@` or `@:` syntax, it seems clearer that attributes are part of the class/function/property declaration, rather than their own standalone construct which docblocks can be applied to: /** * A comment describing things. * * @psalm-suppress SomeRule */ @@ORM\Entity @@ORM\Table("baz") final class Something { } Given that the only complex part of an attribute is the optional argument list, which already has its own start/end delimiters, I ultimately don't find the "complexity" argument very compelling for needing an additional attribute end delimiter besides. 2. In the **Discussion on grep'ability** section, the RFC says "Enforcement of same line is also not the case for other declarations that benefit from grep'ability such as classes, functions, constants and so on in PHP already, so this is not consistent within the language." This seems to be outdated information, based on Martin's original patch before the "Treat namespaced names as single token" RFC was accepted. In the current `@@` implementation, there is no single-line enforcement, consistent with other parts of the language. Not having whitespace between the attribute token and name would be enforced by coding style conventions, just as is the case with function/class/constant definitions. Note that there is some precedent in PHP for choosing syntax that ensures easier searching (for example, the decision to place return type declarations after the parameter list rather than before the function name). Grep'ability isn't a big deal when finding usages in an IDE, but sometimes there is a need to search code on a server or other source without an IDE, in which case easy grep'ability can be very helpful. Sincerely, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
