Re: [RFC] Shorter Attribute Syntax Change RFC 0.2

On Wed, Aug 19, 2020 at 12:03 AM Theodore Brown <theodorejb@outlook.com> wrote: > On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei <kontakt@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. > Right, i didn't realize this restriction was lifted and updated this section. This doesn't change the argument though that when you need coding styles to enforce a particular style that grepability works, then you can find a coding standard with all syntaxes that has good grepability, i.e. by not using grouping. > > 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