Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110410
To: Rowan Tommins <rowan.collins@gmail.com>, internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter attribute syntax
Thread-Index: AQHWOgIv0rCwDWp4oECJgOMrWx9MxKjItJCAgABT1+2AAnlHgIAB4RWM
Date: Sun, 7 Jun 2020 18:37:01 +0000
Message-ID:
 <BYAPR05MB6535D02144B77539BC92F5C3DE840@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>
In-Reply-To: <a589a9bc-67e8-e427-53ef-30b53525c388@gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [5W8Oylb+tfoK8ji9iojMerd1GPTmba1J]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: ee7e886b-c0ff-4545-57d8-08d80b11c4ed
x-ms-traffictypediagnostic: BN8NAM12HT168:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 EYBV1xrZZlcIdz1dlU8O59CdjbaIV+Tp2xV0/A0mjaPPf4ycN6fQmeUhktk/3q75ulTioNbHcPbnjofoOjs2B7qBoRbW2sttxdTgD2iVM9woFRg6dE5x2uuvN31tG35tTO04aVyoaeeL3e2hCaUUAQYhiZJjuc0OYD4WVNShu30JLS4bTLc5v1HI+u++v4vH7/0PukaHTOqAkyo+b6/0sA==
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:
 lsX7wn5VuobjlVdqEQZkl3t5PrxEIaUDH25q4iXGTU6jAVbdp3cFKL+OtEZSdZ2T5oXx6Mnxtm7cgrswVYlnJlQVu7pHVLUGj8Mvnbg+lZP5Uxa6zWvYihu461iJbaThWGYm+jPtt52Juy3kbeSjrA==
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: ee7e886b-c0ff-4545-57d8-08d80b11c4ed
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2020 18:37:01.8424
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM12HT168
Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax
From: theodorejb@outlook.com (Theodore Brown)

Hi Rowan,=0A=
=0A=
On Sat, June 6, 2020 at 7:06 AM Rowan Tommins <rowan.collins@gmail.com> wro=
te:=0A=
=0A=
> The `::` token in the parser is called `T_PAAMAYIM_NEKUDOTAYIM`, and =0A=
> personally I find `T_SL` and `T_SR` just as cryptic and irrelevant. The m=
ost =0A=
> common place I see those token names is when accidentally running code =
=0A=
> with conflict markers like "<<<<<<<<", or when messing up heredoc =0A=
> syntax; even if they weren't so abbreviated, my reaction would be "shift =
=0A=
> what now?" I've used bit-shifts maybe twice in the last ten years, so =0A=
> it's just not an immediate association to me.=0A=
>=0A=
> "Disingenuous" was probably too strong a word, but I do think it relates =
=0A=
> to a fundamental difference in viewpoint: to some people, `<<` and `>>`=
=0A=
> are first and foremost the shift-left and shift-right operators, and so=
=0A=
> the immediate association on seeing them is so obvious it's not worth=0A=
> mentioning; to others, they just look like a new kind of brackets.=0A=
> =0A=
> That association might actually be a good reason to avoid that syntax, =
=0A=
> but if so it should be spelled out, rather than taken as a given.=0A=
=0A=
That makes sense. I updated the RFC now to avoid usage of "shift tokens"=0A=
in most places and instead refer to them as `<<` and `>>` tokens. I also=0A=
added a sentence spelling out why the association with shift operators=0A=
may be confusing for some developers.=0A=
=0A=
Additionally, the RFC more clearly lays out the issues with nested=0A=
attributes now.=0A=
=0A=
> > Also, grouped attributes would probably have to be special-cased to=0A=
> > be disallowed in nested attributes, since they don't make sense there.=
=0A=
> =0A=
> I'm not entirely clear how they work in current implementations like =0A=
> Doctrine's, but I think nested attributes would have to have completely =
=0A=
> different rules anyway, because you don't access them directly through =
=0A=
> reflection in the same way.=0A=
> =0A=
> If `<<Foo( <<Bar>> )>>` means something like `new Foo( new Bar )`, then I=
 =0A=
> can imagine it being useful for `<<Foo( <<Bar, Baz>> )>>` to mean=0A=
> `new Foo( [new Bar, new Baz] )`. That would actually be more convenient t=
han=0A=
> the double-at version, where you'd have to write `@@Foo( [@@Bar, @@Baz] )=
`=0A=
> or use a constructor with a `...$variadic` parameter.=0A=
=0A=
In that example there are the same number of characters either way, so=0A=
it's not clear the nested `<<>>` approach would be more convenient.=0A=
And do you think it's a good idea to have an additional syntax for=0A=
creating arrays like that? It seems like it could get confusing.=0A=
=0A=
> Ultimately, it all comes down to judgement calls - is the =0A=
> double-angle-bracket syntax "too verbose", "too ugly" when nested, etc; =
=0A=
> and does the double-at syntax make it "better enough".=0A=
=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=
Best regards,  =0A=
Theodore=