Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111579
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_73502e0ff1e16fd43db2613ccfa5ffe3"
Date: Mon, 17 Aug 2020 14:30:55 +0200
To: Andreas Leathley <a.leathley@gmx.net>
Cc: internals@lists.php.net
In-Reply-To: <4fae771b-7e02-f34d-48b2-345d7c0cb09f@gmx.net>
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl> <CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
 <4fae771b-7e02-f34d-48b2-345d7c0cb09f@gmx.net>
Message-ID: <5bb74053737eeccb061b1b0df79b2e6b6c4ea91658b7b0e53af6ab780ecf1eb7@mahalux.com>
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: vorismi3@fel.cvut.cz (=?UTF-8?Q?Michael_Vo=C5=99=C3=AD=C5=A1ek_-_=C4=8CVUT_FEL?=)

--=_73502e0ff1e16fd43db2613ccfa5ffe3
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8; format=flowed

> possibility to keep @@ and add @{} as a second syntax for attributes

+1, but I would keep same prefix, ie. @@{} (or @@[]), for both syntaxes,
it is much easier for human eyes to search for one thing, also easier
for grep 

With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek

On 17 Aug 2020 12:48, Andreas Leathley wrote:

> As a possible addition/discussion point, I only noticed today that @{}
> is a syntax that has not been mentioned yet, also not in any previous
> discussions about attributes as far as I can tell. @{} currently leads
> 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.
> 
> 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.
> 
> 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 foreseeing
> each individual use case, and maybe attributes is such a feature.
> 
> 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 not
> have a BC break, so these two option might be good together.
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
--=_73502e0ff1e16fd43db2613ccfa5ffe3--