On Sun, Aug 16, 2020 at 1:00 AM Benjamin Eberlei <kont...@beberlei.de> wrote:
>>
>> The RFC says that
>> > 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.
>> However, it's clear that attributes are neither a declaration nor a
>> statement, but metadata about the thing that follows them (unless it's
>> more attributes or comments).
>> The ultimate proof of this is that a semicolon after an attribute is illegal.
>
> I would like to chime in here since this argument is made over and over
> again, even though it overlooks an important point. when we say that
> attributes are just metadata, then let's compare them to docblocks with *are*
> always enclosed in /** and */ instead of visibility keywords.
>
> This comparison is fair, because doc comments are often multi line and
> attributes are as well. When doc comments are single line, they are also
> enclosed.
>
> Whereas a comparison with visibility modifiers that are *just* tokens that
> *always* are followed by a T_WHITESPACE is apples vs oranges, because @@
> attributes can be followed by a large set of different things:
>
> @@Foo @@Bar // ends due to T_WHITESPACE with " "
> @@Foo // ends due to T_WHITESPACE with "\n"
> @@Foo() // ends due to )
> @@Foo () // ends with ), the T_WHITESPACE between class and arguments is
> valid
> @@Foo@@Bar // ends due to new T_ATTRIBUTE
> @@Foo()@@Bar // ends due to )
> @@Foo
> ("bar") // ends here in the second line at )
> function a_function() {
> }
>
Hi Benjamin,
I'm sorry, but I don't understand your argument.
It's true that annotations used to be enclosed in a docblock, but that
is not an argument for saying that attributes NEEDS to be enclosed in
a block too.
It's also true that attributes can be followed by many different
things, but still it doesn't follow that block enclosing is NECESSARY.
What I'm saying is that there is still no good argument for why
attribute block syntax is better than non-block syntax.
The only argument that was presented in the original RFC was not
convincing, and I pointed out why.
I'm also not saying that non-block syntax is better.
Hence, it seems it's just a matter of taste, so far - unless we get to
see some convincing arguments in the rewritten RFC.
Thanks,
Jakob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
