On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown <theodor...@outlook.com> wrote:
> On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans <der...@php.net> wrote: > > > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute > > Syntax Change RFC to reflect that process: > > > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > > > Patches and comments welcome. > > Hi Derick, > > I don't agree with the main argument put forward in this RFC: > > > The main concern is that @@ has no ending symbol and it's > > inconsistent with the language that it would be the only > > declaration or statement in the whole language that has no ending > > termination symbol. > > Attributes are not a standalone statement or declaration; they are > metadata *on* a declaration. They cannot stand alone, but always > modify the following declaration, just as public and static modify > a method, or a type declaration modifies a parameter or property. > > Modifying declarations (e.g. for visibility and type) do not have an > ending symbol. For example, we don't write something like: > > [public] function foo([int] $bar) {} > > With the @@ syntax attributes a treated consistently with type and > visibility declarations: > > @@Jit > public function foo(@@Deprecated int $bar) {} > > So there is nothing inconsistent about not having a termination > symbol - this is in harmony with visibility and type declarations in > PHP, as well as the attribute syntax used by a majority of C family > languages. [1] > Attributes are potentially way more complex than a visibility keyword. As such it is a reasonable requirement to say they should have a unified ending symbol, or more broadly speaking that attributes should be enclosed by syntax. It looks nice for a simple attribute like @@Jit, or for a one without arguments like the used @@Deprecated, but as soon as there are more than one, and they each get arguments, enclosing them has its own benefits over them just standing for themselves. > > When it comes to supporting attribute grouping, I actually consider > this a downside of the #[], @[], and <<>> syntaxes. It complicates > the internal implementation, and makes it so developers have to > choose between two different syntaxes when adding more than one > attribute. In real-world use cases the @@ syntax is just as or even > more concise without the extra parser/compiler complexity: > > #[Attr1, Attr2] # 15 chars > > @@Attr1 @@Attr2 # 15 chars > > # 4 lines, 53 chars not counting whitespace > @[ > AttrWithParam("foobar"), > SomeOtherAttr("fizzbuzz"), > ] > > # 2 lines, 52 chars > @@AttrWithParam("foobar") > @@SomeOtherAttr("fizzbuzz") > > I agree that we want the best syntax, not necessarily the best > **looking** syntax. I still believe that the @@ syntax offers the best > balance here. It's familiar, concise without additional complexity, > and doesn't break useful syntax the way @[] and #[] do. > Yes, we have been doing this for 20 years, adding annotations enclosed with /** and */ with each enclosing on its own line for the most part. We even added stars in front of every inbetween line. we are stepping into unchartered territory here with @@ by our standards as PHP community. Using "C familiy" as an argument that they made @ work does not mean much, because the language itself is just the "interface" to the implementation, each C family language probably has vastly different parsers, concerns and approaches. It should be right for PHP. > Kind regards, > Theodore > > [1]: > https://wiki.php.net/rfc/shorter_attribute_syntax#comparison_to_other_languages > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
