Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110436
To: Larry Garfield <larry@garfieldtech.com>, php internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter attribute syntax
Thread-Index:
 AQHWOgIv0rCwDWp4oECJgOMrWx9MxKjItJCAgABT1+2AAnlHgIAB4RWMgABgUwCAAE4Q4IAAxkKAgABeMFI=
Date: Mon, 8 Jun 2020 20:40:56 +0000
Message-ID:
 <BYAPR05MB6535ACD66049FDAE43DE9E87DE850@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>
 <BYAPR05MB653545D79EC9CFE5D4B19D61DE850@BYAPR05MB6535.namprd05.prod.outlook.com>,<dc67a415-52e6-4380-b121-dc61fdd2cb46@www.fastmail.com>
In-Reply-To: <dc67a415-52e6-4380-b121-dc61fdd2cb46@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [VfyskEtzRZ5dA8JsKDxkcrvJqTwRAJA9]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: f5b25a99-ffa5-4385-d328-08d80bec3eae
x-ms-traffictypediagnostic: DM6NAM11HT020:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 +PdlkvaQ5FEzt6B2Mu3TBh8chFieV3TcwnJN84Ehy/WQaEK9tflDxZK6EQcGYE/EFWXZ0EX3vBo6BolOqnB0u1K0lILMA4AxpFJb/IZ72cZmsz0+UTmV75kSy96FjMru3Onr7lSDyrW0V71NG7h9tpWKeTPrAwlruBAuC+QQtr+Rr631qbrJ8tMk1ibFw44Z1Q4dGcSxihdGCxEDfpgdwHiiQiFQh+D/5AlSqvsPD3l+JgVE5u3Dzcmqo9mf3xIL
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:
 l5YQRR/DiOzDP5QdPK+EOh0HLhZhy8w9IeqUL/++QsxqGqvqWSWkKOYhf3SE+aq/awy8+4Uo5gLocLsMwGdzxvAJauaLm50SOIZ7U8bhCmztdT3xKhz+JHuSgOD4FOaeDiQs+cVcRw6MLRn0R3+0tg==
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: f5b25a99-ffa5-4385-d328-08d80bec3eae
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 20:40:56.4247
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT020
Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax
From: theodorejb@outlook.com (Theodore Brown)

On Mon, June 8, 2020 at 10:01 AM Larry Garfield <larry@garfieldtech.com> wr=
ote:=0A=
=0A=
> FWIW, I find both alternatives ugly to my eye. So, there's that.  =0A=
>=0A=
> Given that `@` is off the table for obvious reasons, my preference=0A=
> would frankly be for Rust's `#[]`, which has the nice side effect=0A=
> of being a normal comment in earlier PHP versions and so attributes=0A=
> can be included as optional without breaking BC. I don't know if=0A=
> that's a big deal or not, but it's a benefit. And it should be no=0A=
> harder on the parser to differentiate than `@` vs `@@` is.=0A=
>=0A=
> (The only advantage of `@@` in my mind is another obvious Star Wars=0A=
> joke.)=0A=
=0A=
Hi Larry,=0A=
=0A=
From the perspective of looks I don't have a strong preference=0A=
between them. There are two main reasons I decided against borrowing=0A=
the `#[]` syntax from Rust:=0A=
=0A=
1. It's a much larger BC break. Disallowing comments from starting=0A=
with a certain character could break a lot of code in the wild.=0A=
From a quick search of grep.app, I found two examples on the first=0A=
page of results using `#[` as a comment. [1] Is it worth breaking=0A=
this code?=0A=
=0A=
2. `#[]` is slightly more verbose, which works against one of the=0A=
objectives of the RFC. Rust is the only language I found that uses=0A=
three characters for its attribute syntax like this.=0A=
=0A=
I actually starting trying to draft an RFC which would propose the=0A=
`#[]` syntax for attributes, but one thing I noticed while doing=0A=
so is that (at least on my QWERTY keyboard) `#[` is noticeably=0A=
harder to type - I kept typoing it as `#]` or `#\`. This is dependent=0A=
on keyboard layout, of course, but being prone to accidental typos=0A=
was also one of the arguments against the `@:` syntax in the original=0A=
RFC.=0A=
=0A=
> Something that I don't think has been addressed explicitly in this=0A=
> thread yet is single line vs separate line attributes.  Vis:=0A=
> =0A=
> `<<Foo>> class Blah {}`=0A=
>=0A=
> vs.=0A=
>=0A=
> ```php=0A=
> <<Foo>>=0A=
> class Blah {}=0A=
> ```=0A=
>=0A=
> Syntactically both are legal AFAIK; I don't know which most people =0A=
> will do. The separate line version seems more likely, and cleaner =0A=
> to me, but for parameters people may want to inline it in shorter =0A=
> signatures. Or it may push people to always multi-line those=0A=
> function definitions, for better or worse. (I find that quite ugly=0A=
> myself, but I don't know if I'm in the majority on that view.)=0A=
>=0A=
> My gut feeling is that `@@` is notably worse inline. It subjectively=0A=
> feels messier because there's no clear indication of where the end=0A=
> is. On separate lines, `@@` and `<< >>` seem about equally ugly to me.=0A=
=0A=
Personally I have the opposite reaction when it comes to inline=0A=
parameter attributes - the closing `>>` always looks like a shift=0A=
operator at first glance which makes it harder for me to read. And=0A=
for an inline function or class attribute the function/class keyword=0A=
already provides a strong indication of where the attribute ends.=0A=
=0A=
But for anything other than very short attributes, I expect most=0A=
people will want to put the attribute on a separate line for optimal=0A=
readability, regardless of the final syntax:=0A=
=0A=
```php=0A=
function foo(=0A=
    <<ExampleAttribute("foo", "bar")>>=0A=
    <<OtherAttribute(123, ["key" =3D> "val"])>>=0A=
    Type $myParam,=0A=
    bool $param2,=0A=
) {=0A=
    ...=0A=
}=0A=
=0A=
// vs.=0A=
=0A=
function foo(=0A=
    @@ExampleAttribute("foo", "bar")=0A=
    @@OtherAttribute(123, ["key" =3D> "val"])=0A=
    Type $myParam,=0A=
    bool $param2,=0A=
) {=0A=
    ...=0A=
}=0A=
```=0A=
=0A=
Best regards,  =0A=
Theodore=0A=
=0A=
[1]: https://grep.app/search?q=3D%23%5B&filter[lang][0]=3DPHP=0A=