Hi Derick,
> 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]
>
> 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.
>
> Kind regards,
> Theodore
I agree with Theodore's points, including that this is metadata on a
declaration, not a declaration itself.
This RFC has proposed that the lack of a closing delimiter might get in the way
of future language changes,
but has not given examples of hypothetical syntax extensions that would cause
future conflict
and that it'd be impossible to resolve/avoid the ambiguity.
(e.g. Java has managed with `@AttributeName` and optional arguments in
parameters, classes, properties, methods, etc.)
PHP already has a lot of places where there is no closing delimiter, even where
you'd want/expect one,
so I wouldn't call a lack of closing delimiter unique.
e.g. the below example is parsed as `clone((new stdClass())->foo)`,
because parenthesis aren't part of `clone`.
```
php > clone(new stdClass())->foo;
Notice: Undefined property: stdClass::$foo in php shell code on line 1
Warning: Uncaught Error: __clone method called on non-object in php shell code:1
```
Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
