Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110414
To: Rowan Tommins <rowan.collins@gmail.com>, internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter attribute syntax
Thread-Index:
 AQHWOgIv0rCwDWp4oECJgOMrWx9MxKjItJCAgABT1+2AAnlHgIAB4RWMgABgUwCAAE4Q4A==
Date: Mon, 8 Jun 2020 04:36:50 +0000
Message-ID:
 <BYAPR05MB653545D79EC9CFE5D4B19D61DE850@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CALKiJKrwUA4Mo4HmHVL6ChaQSidpgS3jmc3fqdbZgnob4gk0zg@mail.gmail.com>
 <BYAPR05MB6535BC6C6D0353AE92B6486DDE890@BYAPR05MB6535.namprd05.prod.outlook.com>
 <a589a9bc-67e8-e427-53ef-30b53525c388@gmail.com>
 <BYAPR05MB6535D02144B77539BC92F5C3DE840@BYAPR05MB6535.namprd05.prod.outlook.com>,<5ebecd58-9f39-72b9-369d-dbb60b80af36@gmail.com>
In-Reply-To: <5ebecd58-9f39-72b9-369d-dbb60b80af36@gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [u/w9tk1YpQGeEY6irJMtKC17Zy3wuBK8]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: d8dd390e-5a68-46cb-aa1f-08d80b658fd1
x-ms-traffictypediagnostic: CO1NAM11HT020:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 yAVEdzHJoM2MkBSXMbD2Nm1ylKQA1OQ57JaBsTCSNcRG8uN/rlBIJihm/MfEG77I5NPqvURl6tdmyner0od33CBDDkIi101OKhinC92Oge82CHPNbq9DYhcZ0sMIwYvIkKKOMVF4HdYcGD9/rjxFSXG6vZ9IGpNCEKWc3CbQam7FUo9M5+qUwc2/nXQqNn/gJ342k1jWvcgrTLhVVl3aw9mY4xzVnzPDSSai7CwzGkZAGlKS4U7UKKF3dAg93gWd
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR05MB6535.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 BUrvYTTrS3lsyzn2M38JH1wirkZqVNfynNwuVLDeoGqhZKEETJe0MakgHEwsV5LOylUn2Zr6n/Y+PzlbfF/CzCFcRXlrIdmXUjMKy5XzjJLWWy03dBnwcY8NTQPCda50srUx+Ny4sgXIcEoHT/moqA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d8dd390e-5a68-46cb-aa1f-08d80b658fd1
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 04:36:50.4910
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT020
Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax
From: theodorejb@outlook.com (Theodore Brown)

Hi Rowan,=0A=
=0A=
On Sun, June 7, 2020 at 5:32 PM Rowan Tommins <rowan.collins@gmail.com> wro=
te:=0A=
=0A=
> On 07/06/2020 19:37, Theodore Brown wrote:=0A=
> > Yes, I agree that there's a judgment call to make. Out of curiosity,=0A=
> > given these shortcomings of the double-angle-bracket syntax, do you=0A=
> > think there are any objective reasons to prefer it over `@@` (other=0A=
> > than the theoretical BC break of code like `@@@really_suppress_me()`)?=
=0A=
> =0A=
> I'm not convinced there's any objective reasons to be found either way, =
=0A=
> but for the sake of "playing devil's advocate", here are a few that =0A=
> could be put forward:=0A=
> =0A=
> If grouped attributes are added, they're actually slightly less verbose =
=0A=
> than repeating a double-at prefix, once you have enough attributes in =0A=
> the set:=0A=
> =0A=
> Minimum spacing and punctuation requires n+3 chars vs 3n, so a saving =0A=
> even with 2 attributes:=0A=
> `<<Foo,Bar>>class Bob{}`  =0A=
> vs  =0A=
> `@@Foo @@Bar class Bob{}`=0A=
> =0A=
> More realistic spacing is 2n+3 vs 3n, giving a saving only with 4 or more=
:  =0A=
> `<<Foo, Bar, Baz, Quux>>class Bob{}`  =0A=
> vs  =0A=
> `@@Foo @@Bar @@Baz @@Quux class Bob{}`=0A=
=0A=
Neither of these are realistic examples, though. In practice, you're=0A=
not going to have an empty class definition on the same line as a=0A=
bunch of short attributes like this. Based on the Use Cases section=0A=
of the Attributes v2 RFC, [1] typically there would be three or fewer=0A=
attributes applied to a given entity.=0A=
=0A=
The RFC only has one example with four attributes, which happens to be=0A=
a flattened version of the nested attributes use case discussed in the=0A=
Shorter Attribute Syntax RFC. But in this example, the attributes each=0A=
have one or more parameters, which makes them long enough that they=0A=
have to be on separate lines. And with sane formatting, the `<<>>`=0A=
syntax version still ends up being more verbose:=0A=
=0A=
```php=0A=
// 170 characters for attributes (162 not counting leading whitespace)=0A=
<<=0A=
  ManyToMany(Phonenumber::class),=0A=
  JoinTable("users_phonenumbers"),=0A=
  JoinColumn("user_id", "id"),=0A=
  InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE),=0A=
>>=0A=
private $phonenumbers;=0A=
=0A=
// 160 characters for attributes=0A=
@@ManyToMany(Phonenumber::class)=0A=
@@JoinTable("users_phonenumbers")=0A=
@@JoinColumn("user_id", "id")=0A=
@@InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)=0A=
private $phonenumbers;=0A=
```=0A=
=0A=
So the idea that the `<<>>` syntax with grouped attributes will be=0A=
less verbose than the `@@` syntax turns out not to be the case in=0A=
real-world use cases.=0A=
=0A=
> Bracket-based syntaxes, particularly with grouping, are more clearly =0A=
> separated from the main code, particularly when used inline. For instance=
:=0A=
> =0A=
> `$f =3D @@Something @@AnotherThing function(@@Special @@ReallyInt int $va=
r) {};`  =0A=
> vs  =0A=
> `$f =3D <<Something, AnotherThing>> function(<<Special, ReallyInt>> int $=
var) {};`=0A=
=0A=
To me there doesn't seem to be a big difference in readability between=0A=
the function attributes in this example. And with syntax highlighting,=0A=
the function keyword itself provides a very clear separation.=0A=
=0A=
For the parameter attributes, the `@@` syntax example is actually=0A=
more readable to my eye. I can't help seeing the `>>` token as a=0A=
shift operator at first glance in this context.=0A=
=0A=
> Finally, typing up those examples, it occurs to me that `@@` is quite a =
=0A=
> "heavy" symbol - it has a large proportion of black (or whatever colour) =
=0A=
> pixels - and inevitably a rather "fussy" one. I find it draws the eye =0A=
> more than the angle-brackets do, which feels unfortunate.=0A=
=0A=
I guess this is somewhat dependent on the font you're using. But in=0A=
general I don't think that the symbol being "heavy" is necessarily=0A=
a bad thing. It can help attributes stand out better from function=0A=
calls, generics, and other nearby syntax.=0A=
=0A=
Best regards,  =0A=
Theodore=0A=
=0A=
[1]: https://wiki.php.net/rfc/attributes_v2#use_cases=0A=