Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110380
To: Rowan Tommins <rowan.collins@gmail.com>, internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter attribute syntax
Thread-Index: AQHWOgIv0rCwDWp4oECJgOMrWx9MxKjItJCAgABT1+0=
Date: Thu, 4 Jun 2020 22:20:00 +0000
Message-ID:
 <BYAPR05MB6535BC6C6D0353AE92B6486DDE890@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>,<CALKiJKrwUA4Mo4HmHVL6ChaQSidpgS3jmc3fqdbZgnob4gk0zg@mail.gmail.com>
In-Reply-To:
 <CALKiJKrwUA4Mo4HmHVL6ChaQSidpgS3jmc3fqdbZgnob4gk0zg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [Wzi8AuLqe7V01HQe15cYpFDbp3p+saTU]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 25c2b83a-cc8a-4c98-e3bd-08d808d56c11
x-ms-traffictypediagnostic: CO1NAM11HT217:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 FS1w2SJPXimZEplaVnaoFz4yxkX0drIW0EN5OOtXM6Xpo9abgSRCnhy6mYmN5h2WwMM9QV4ifTbZNS7gisOpuA81ylMGLYRCJOR/RLsiaGm1bYMjMc0qfeGcy7Ed+hLIO5T9AM4vOs5QABoCPTnA7FibwzDxLHldoU6AtcQn70E7aDZJkMkEM22GpILo5ASfA5t8wV51RVTZ/8frwYQVsg==
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:
 k5RJatTnIzBVchG3RwmZmQwjtxuMb+rKCRxx/ifZ1+R1gPxzIMETx4wsUZ7uXj4Rqa2o3w1fjIZJImr6wiOLswA6EAaWI2dSl1nZ7nJh04UR/g+aBAlCK2HK5CN3bVfNuNa92a8++NvTmJasoy7DsA==
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: 25c2b83a-cc8a-4c98-e3bd-08d808d56c11
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 22:20:00.6673
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT217
Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax
From: theodorejb@outlook.com (Theodore Brown)

On Thu, June 4, 2020 at 12:19 PM Rowan Tommins <rowan.collins@gmail.com> wr=
ote:=0A=
=0A=
> Hi Theodore,=0A=
=0A=
Hi Rowan,=0A=
=0A=
Thanks for the feedback. I added replies inline.=0A=
=0A=
> I find the "objective" reasons in this RFC to be greatly exaggerated.=0A=
> =0A=
> 1. `@@Jit` does not require "half as many characters" as `<<Jit>>`;=0A=
> even for this, which is probably the shortest attribute anyone will=0A=
> ever use, the saving is less than 30%; for more common attributes=0A=
> which resemble entire function calls, it will be a tiny proportional=0A=
> saving.=0A=
=0A=
By "half as many characters" the RFC is referring to the attribute=0A=
syntax itself, not the name/arguments of the attribute being used.=0A=
You're right that with longer attributes, the attribute syntax makes=0A=
up a smaller percentage of the code. However, I'd argue the savings=0A=
still has value even when it's a smaller proportion.=0A=
=0A=
> 2. You don't actually explain why `@@Foo` would be any easier to=0A=
> integrate with nested attributes than `<<Foo>>`. Is there some=0A=
> parser conflict that applies to one and not the other?=0A=
=0A=
Martin can correct me if I'm wrong here, but I believe nested attributes=0A=
are syntactically possible with the `<<>>` syntax, but "ugly as sin"=0A=
(to quote Nikita). For example:=0A=
=0A=
```php=0A=
<<JoinTable(=0A=
    "User_Group",=0A=
    <<JoinColumn("User_id", "id")>>,=0A=
    <<JoinColumn("Group_id", "id")>>,=0A=
)>>=0A=
private $groups;=0A=
```=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=
During implementation a bunch of work was put into trying to support=0A=
nested attributes with `new` (e.g. `new JoinColumn("User_id", "id")`),=0A=
but as the RFC mentions this was given up on since it turned out to be=0A=
very difficult to implement and would require lots of changes to const=0A=
expressions.=0A=
=0A=
> 3. While confusion with generics is possible, I would be interested=0A=
> to hear from C# programmers how often they confuse `[Attribute]` for=0A=
> an array index operation, or any of the other uses of square brackets.=0A=
=0A=
One reason I think confusion with generics is more probable is that=0A=
generics and attributes would frequently be used in a similar location=0A=
(near the start of a class declaration).=0A=
=0A=
> 4. Similarly, I've yet to see anyone point to an example of confusion=0A=
> with shift operators that's not extremely contrived. I could come up=0A=
> with equally contrived examples where an attribute contained e-mail=0A=
> addresses and twitter handles, making `@@` look confusing.=0A=
=0A=
Perhaps, though this seems much less likely since email addresses and=0A=
twitter handles would be in a string, whereas `<<` is a standalone=0A=
token used outside of strings.=0A=
=0A=
> 5. No other language has been put forward using the `@@` operator. It=0A=
> more closely resembles those languages that use a single `@`, but the=0A=
> `<<Foo>>` syntax more closely resembles those languages that use some=0A=
> form of brackets.=0A=
=0A=
Fair enough. This doesn't really seem like an argument one way or=0A=
another.=0A=
=0A=
> I also find it disingenuous that you refer to the `<<Foo>>` syntax as=0A=
> "the shift tokens" throughout, but do not similarly call your proposed=0A=
> syntax "the double-suppression token". If one is "double-at", then the=0A=
> other is "double-angle-brackets".=0A=
=0A=
I don't understand how it's disingenuous. The RFC refers to the shift=0A=
tokens as such because that's what they are (`T_SL` and `T_SR`). The=0A=
proposed `@@` syntax uses a new `T_ATTRIBUTE` token.=0A=
=0A=
> The one convincing *objective* argument I've seen is Jordi's, that=0A=
> `@@` would be easily greppable. Interestingly, that's not true of=0A=
> any of the other languages listed in the comparison other than Rust's=0A=
> hash-bracket and maybe C++'s double-bracket, but that doesn't mean we=0A=
> can't do better.=0A=
=0A=
Yes, I this is one reason I think having an `@@` token is a good fit=0A=
for PHP, as preserving easy greppability has influenced other syntax=0A=
decisions as well (e.g. the placement of return types).=0A=
=0A=
> Other than that, I think it really comes down to a matter of taste. Some=
=0A=
> people reacted to the `<<Foo>>` syntax the way they did to the Cats movie=
=0A=
> trailer, and may react to this one better. That's fine; we can make a=0A=
> decision for subjective reasons, but let's be honest and say that.=0A=
=0A=
Well, I guess the line between objective and subjective may sometimes=0A=
be a bit subjective. :)=0A=
=0A=
Best regards,  =0A=
Theodore=0A=