Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111343
To: Benjamin Eberlei <kontakt@beberlei.de>
CC: Derick Rethans <derick@php.net>, PHP Developers Mailing List
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Thread-Index: AQHWamWKUBRwNDrYsUOzfoBQKi8o6KkoJexGgAFK3ICAAEoRXA==
Date: Wed, 5 Aug 2020 16:46:31 +0000
Message-ID:
 <BYAPR05MB6535960204EC6C755AFA83BADE4B0@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB6535AE9831221566469C4503DE4A0@BYAPR05MB6535.namprd05.prod.outlook.com>,<CAEPJdu=9veECGqaUDwHqHWRWk0m0qrzGLs6fnmBa9D5OY6wMqQ@mail.gmail.com>
In-Reply-To:
 <CAEPJdu=9veECGqaUDwHqHWRWk0m0qrzGLs6fnmBa9D5OY6wMqQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [Iu6VDyhKmS6BOPt/mF2TSJ0aC9kRWCrx]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 075e4125-b8d2-46cd-4b5d-08d8395f1ba9
x-ms-traffictypediagnostic: CO1NAM04HT149:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 oLNf5zLD7oMw8IpSyqEZgEY1oAhFMJVmp+t22GQOkIqzT4ZB+Tj3dT/p3E7ORXqkdmHaaw1qi+m0HvSfd34c95U7vZkyA6J2SOxQyWHGqPURAjVIpgzv5iiqJzAXU0F67NOx/8nq2PfoXAAXpa8lCzTKA0aZ17yAR0Td/3D3CiIrM+UOF3yR+oFK0fTu2A+x1t3tqevtfTaRXhUakszXHznACWJMM1nWRID8Ffk+GI6PzgRd1/WBY0qnsoT5OFoK
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:
 SgDxBd/KyT3915LYJU5D26ktcJVT+KfdZhtjah7LW9eaKOETQDekT5bPKmbaOdVPm49ZCN/vEy3bqAN8ihEtv1uBgkSh7OaWFiQnfECQYAdbCHdo1oh0Lyjoh2Dkjnzc8A6ybQGe9zkg7PhrrPGcCw==
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-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: CO1NAM04FT056.eop-NAM04.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 075e4125-b8d2-46cd-4b5d-08d8395f1ba9
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 16:46:31.6903
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT149
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: theodorejb@outlook.com (Theodore Brown)

On Wed, Aug 5, 2020 at 7:20 AM Benjamin Eberlei <kontakt@beberlei.de> wrote=
:=0A=
=0A=
> On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown wrote:=0A=
> > On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans <derick@php.net> wrote:=
=0A=
> > =0A=
> > > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute=
=0A=
> > > Syntax Change RFC to reflect that process:=0A=
> > >=0A=
> > > https://wiki.php.net/rfc/shorter_attribute_syntax_change=0A=
> > >=0A=
> > > Patches and comments welcome.=0A=
> > =0A=
> > Hi Derick,=0A=
> > =0A=
> > I don't agree with the main argument put forward in this RFC:=0A=
> > =0A=
> > > The main concern is that @@ has no ending symbol and it's=0A=
> > > inconsistent with the language that it would be the only=0A=
> > > declaration or statement in the whole language that has no ending=0A=
> > > termination symbol.=0A=
> > =0A=
> > Attributes are not a standalone statement or declaration; they are=0A=
> > metadata *on* a declaration. They cannot stand alone, but always=0A=
> > modify the following declaration, just as public and static modify=0A=
> > a method, or a type declaration modifies a parameter or property.=0A=
> > =0A=
> > Modifying declarations (e.g. for visibility and type) do not have an=0A=
> > ending symbol. For example, we don't write something like:=0A=
> > =0A=
> >     [public] function foo([int] $bar) {}=0A=
> > =0A=
> > With the @@ syntax attributes are treated consistently with type and=0A=
> > visibility declarations:=0A=
> > =0A=
> >     @@Jit=0A=
> >     public function foo(@@Deprecated int $bar) {}=0A=
> > =0A=
> > So there is nothing inconsistent about not having a termination=0A=
> > symbol - this is in harmony with visibility and type declarations in=0A=
> > PHP, as well as the attribute syntax used by a majority of C family=0A=
> > languages. [1]=0A=
>=0A=
> Attributes are potentially way more complex than a visibility keyword.=0A=
> As such it is a reasonable requirement to say they should have a=0A=
> unified ending symbol, or more broadly speaking that attributes should=0A=
> be enclosed by syntax.=0A=
=0A=
Hi Benjamin,=0A=
=0A=
Yes, attributes that take arguments are more complex than a=0A=
visibility keyword. Union types can also be more complex.=0A=
Nevertheless it is consistent for these declaration modifiers to=0A=
not have an ending symbol.=0A=
=0A=
> It looks nice for a simple attribute like @@Jit, or for a one without=0A=
> arguments like the used @@Deprecated, but as soon as there are more=0A=
> than one, and they each get arguments, enclosing them has its own=0A=
> benefits over them just standing for themselves.=0A=
=0A=
Can you clarify what benefits there are to enclosing them as soon as=0A=
there is more than one attribute with arguments? From my perspective=0A=
this just adds needless complexity without being more concise than=0A=
the @@ syntax.=0A=
=0A=
To me it also looks somewhat strange and less readable to require=0A=
both a closing parenthesis and a closing bracket when an attribute=0A=
has arguments:=0A=
=0A=
    #[MyAttr(=0A=
        "some value",=0A=
        [1, 2, 3],=0A=
        namedArg: true,=0A=
    )]=0A=
=0A=
    # vs.=0A=
=0A=
    @@MyAttr(=0A=
        "some value",=0A=
        [1, 2, 3],=0A=
        namedArg: true,=0A=
    )=0A=
=0A=
> > When it comes to supporting attribute grouping, I actually consider=0A=
> > this a downside of the #[], @[], and <<>> syntaxes. It complicates=0A=
> > the internal implementation, and makes it so developers have to=0A=
> > choose between two different syntaxes when adding more than one=0A=
> > attribute. In real-world use cases the @@ syntax is just as or even=0A=
> > more concise without the extra parser/compiler complexity:=0A=
> > =0A=
> >     #[Attr1, Attr2] # 15 chars=0A=
> > =0A=
> >     @@Attr1 @@Attr2 # 15 chars=0A=
> > =0A=
> >     # 4 lines, 53 chars not counting whitespace=0A=
> >     @[=0A=
> >         AttrWithParam("foobar"),=0A=
> >         SomeOtherAttr("fizzbuzz"),=0A=
> >     ]=0A=
> > =0A=
> >     # 2 lines, 52 chars=0A=
> >     @@AttrWithParam("foobar")=0A=
> >     @@SomeOtherAttr("fizzbuzz")=0A=
> > =0A=
> > I agree that we want the best syntax, not necessarily the best=0A=
> > **looking** syntax. I still believe that the @@ syntax offers the best=
=0A=
> > balance here. It's familiar, concise without additional complexity,=0A=
> > and doesn't break useful syntax the way @[] and #[] do.=0A=
> =0A=
> Yes, we have been doing this for 20 years, adding annotations enclosed=0A=
> with /** and */ with each enclosing on its own line for the most part.=0A=
> We even added stars in front of every inbetween line.=0A=
> =0A=
> we are stepping into unchartered territory here with @@ by our=0A=
> standards as PHP community. Using "C familiy" as an argument that=0A=
> they made @ work does not mean much, because the language itself is=0A=
> just the "interface" to the implementation, each C family language=0A=
> probably has vastly different parsers, concerns and approaches. It=0A=
> should be right for PHP.=0A=
=0A=
I agree that we should pick the syntax that is right for PHP. But how=0A=
are the #[] and @[] alternatives a better fit for the language than=0A=
@@, given that they break useful syntax, while @@ isn't useful for=0A=
anything?=0A=
=0A=
It seems like on the one hand the RFC is arguing that @@ is worse=0A=
because that exact token isn't used by another language, and on the=0A=
other hand it is simultaneously being argued that we need to=0A=
implement a more verbose syntax for adding vague complexity in=0A=
the future that isn't used by any other language. Which is it?=0A=
=0A=
A less vague potential extension is attribute nesting, and @@ is=0A=
arguably the best fit for this - one of the motivations for proposing=0A=
it was to allow attribute nesting while preserving readable code and=0A=
a simple internal implementation.=0A=
=0A=
Best regards,  =0A=
Theodore=