Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111587
User-Agent: Cyrus-JMAP/3.3.0-192-gd9d7a78-fm-20200816.001-gd9d7a786
Mime-Version: 1.0
Message-ID: <2309a26a-1a9f-4fde-84a3-f6a77531501a@www.fastmail.com>
In-Reply-To: 
 <5bb74053737eeccb061b1b0df79b2e6b6c4ea91658b7b0e53af6ab780ecf1eb7@mahalux.com>
References: 
 <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
 <4fae771b-7e02-f34d-48b2-345d7c0cb09f@gmx.net>
 <5bb74053737eeccb061b1b0df79b2e6b6c4ea91658b7b0e53af6ab780ecf1eb7@mahalux.com>
Date: Mon, 17 Aug 2020 10:22:28 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Aug 17, 2020, at 7:30 AM, Michael Vo=C5=99=C3=AD=C5=A1ek - =C4=8C=
VUT FEL wrote:
> > possibility to keep @@ and add @{} as a second syntax for attributes=

>=20
> +1, but I would keep same prefix, ie. @@{} (or @@[]), for both syntaxe=
s,
> it is much easier for human eyes to search for one thing, also easier
> for grep=20
>=20
> On 17 Aug 2020 12:48, Andreas Leathley wrote:
>=20
> > As a possible addition/discussion point, I only noticed today that @=
{}
> > is a syntax that has not been mentioned yet, also not in any previou=
s
> > discussions about attributes as far as I can tell. @{} currently lea=
ds
> > to a syntax error, so there is no BC break, and {} is common syntax =
for
> > grouping expressions in PHP, much more so than [], which is an
> > array-specific syntax.
> >=20
> > Would it be a possibility to keep @@ and add @{} as a second syntax =
for
> > attributes, that can be used for grouping (for situations where that=

> > makes sense) or other possibly future extensions? Then @@ would be a=

> > good syntax for simple attribute definitions, and @{} could be an
> > alternative for people who want to group them or if any more complex=

> > attribute features are added to the language later.
> >=20
> > Because both sides of the "ending delimiter or no ending delimiter"
> > discussion do have some points in their favor, and it seems quite
> > individual what each person prefers. For a language it could be
> > beneficial to give some choices to the developer instead of foreseei=
ng
> > each individual use case, and maybe attributes is such a feature.
> >=20
> > I previously thought about suggesting both types of syntax (with and=

> > without delimiters), but felt the current options all have too many =
side
> > effects to choose "two side effects" or two BC breaks. But the @@ BC=

> > break seems the most harmless BC break of the bunch, and @{} does no=
t
> > have a BC break, so these two option might be good together.


Supporting both @@Foo and @@{ Foo } sounds really nice on the surface as=
 a compromise, but runs into the problem of any 3rd party parsers now ne=
eding to do extra work as well.  Minimizing work for 3rd party parsers i=
s one of the main goals under discussion, as I understand it.  I'm not s=
ure it's viable, therefore, much as it does have its appeal conceptually=
.

--Larry Garfield