Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111551
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008100935570.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB65356FCC029CD06F49F528A0DE420@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CABdc3WobP1HSRwcujd4=o4wv3QUp7gDT12KmMRQU1_wLj4YLuQ@mail.gmail.com>
 <BYAPR05MB65351C807797676BB08D8BDCDE430@BYAPR05MB6535.namprd05.prod.outlook.com>
 <5cc837df-ab47-628a-d29b-46d7933be973@gmx.net> <BYAPR05MB653522F9123B59F7E066BDB8DE430@BYAPR05MB6535.namprd05.prod.outlook.com>
 <3A7CECC3-CDEE-4852-BF4B-4EC7CA1BD538@pmjones.io> <CAAKU0u=VYh7D+XJ93dDdAxdJ8nEU8iPfeN0f=Xv9Qm=cCQKX6w@mail.gmail.com>
 <BN8PR05MB6532D19BEA11F44BAAD3FDD3DE400@BN8PR05MB6532.namprd05.prod.outlook.com>
 <CAESVnVp5NHKKpMHt_7AAO8P9L2vL8UN4ynD5K4d9f23Jvr+s2A@mail.gmail.com>
 <alpine.DEB.2.23.453.2008141902160.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB65352D21FAA7EA37A9A0C37FDE400@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CABdc3Wrd+WECJOXCmYu0Gq5VttVtTkDoO=-9SEP_+-p=qoNB4w@mail.gmail.com>
 <7d6c42a4-53cd-5e38-4ffc-02fe490d66a3@gmx.net> <DM6PR07MB6618E0D524F8E7EDE57B87C2F9410@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAJvSBVPgXXLL0=fN2e3c=+P_x58kE5jsYVRMpGN5yvmWEcCP6g@mail.gmail.com>
 <d4b885c812522de0b014380fffa3dddee52f9cf3f8c9629bfa0d31fbaf18f362@mahalux.com>
 <CAG9XoMRiQSjUPUodDXVCSGwgAC-BhdXVH-vizDRcjgvLt+KKpQ@mail.gmail.com>
 <CAJmjfvVNDRCBOUoaSTPA=Lyhi201ios1uNy_cmBmZ++bGaRvpw@mail.gmail.com> <CAEPJdu=65Sc+ixyJm52iwMaO3EzX4M4Xm5XMRAtt107xixBVBA@mail.gmail.com>
In-Reply-To: <CAEPJdu=65Sc+ixyJm52iwMaO3EzX4M4Xm5XMRAtt107xixBVBA@mail.gmail.com>
Date: Sun, 16 Aug 2020 10:38:57 +0200
Message-ID: <CAJmjfvWcmnjhZ_A6uaZaj3jFr-HPUPOnGm0mdSOLr3Lk094i0Q@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, 
	=?UTF-8?B?TWljaGFlbCBWb8WZw63FoWVrIC0gxIxWVVQgRkVM?= <vorismi3@fel.cvut.cz>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: jakob@givoni.dk (Jakob Givoni)

On Sun, Aug 16, 2020 at 1:00 AM Benjamin Eberlei <kontakt@beberlei.de> wrot=
e:
>>
>> 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 langua=
ge 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 ill=
egal.
>
> I would like to chime in here since this argument is made over and over a=
gain, even though it overlooks an important point. when we say that attribu=
tes are just metadata, then let's compare them to docblocks with *are* alwa=
ys enclosed in /** and */ instead of visibility keywords.
>
> This comparison is fair, because doc comments are often multi line and at=
tributes are as well. When doc comments are single line, they are also encl=
osed.
>
> Whereas a comparison with visibility modifiers that are *just* tokens tha=
t *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