Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111626
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <CAEPJduk12mo-eizR=K7G9TdaMdk7=C5iq88QWwQ6B_tk02r=2w@mail.gmail.com>
 <CAEPJdumb5KmS04-qnGLfHf4mdbSbXcBf_1+67JvWcyyuJDtHZg@mail.gmail.com> <642e48c2-eccc-19d8-99fd-888062a6232e@gmx.net>
In-Reply-To: <642e48c2-eccc-19d8-99fd-888062a6232e@gmx.net>
Date: Wed, 19 Aug 2020 11:12:47 +0200
Message-ID: <CAEPJdumMVXOZCTKH4Ecg7_qrY_+PtnCv4heNtD6_RLBY=FSK4g@mail.gmail.com>
To: Andreas Leathley <a.leathley@gmx.net>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000efb33505ad37686f"
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000efb33505ad37686f
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 19, 2020 at 11:01 AM Andreas Leathley <a.leathley@gmx.net>
wrote:

> On 19.08.20 10:47, Benjamin Eberlei wrote:
> > One last change that I didn't see yesterday as it was on Github and not
> > this list is the addition of another syntax proposal @{} with the same
> > benefits as @[], a little more snowflake than compared to other
> languages,
> > but without the BC Break.
>
> I mentioned the benefits of @{} in an email to this list on Monday, with
> the proposal to have both @@ and @{} as attribute syntax, so both camps
> could have their syntax (one with delimiters, one without) with minimal
> BC breaks, and leave the decision to the PHP developers/projects what
> they prefer in what circumstances, because there can be valid reasons to
> use both - I probably would use both. @{} could be good to define
> multiple attributes for classes/properties, @@ could be good for short
> attributes or ones very entrenched within the code, like function
> parameters. The @{} syntax could be amended in the future, so this would
> also be "future-proof".
>
> But I guess the division about syntax is too big at this point to
> consider an approach where we just offer both types of syntax. From a
> PHP developer viewpoint, it would be preferable though.
>

The "problem" with having both @@ and @{} would be that we would need two
new tokens instead of one.

We have a bunch of proposals that would support both grouped and ungrouped
with the same syntax, so a solution that ends up ending two new tokens and
syntaxes would be less preferable.

With the choice being @@ or @{} - nothing would stop someone (not me ;-))
to make an RFC for 8.1 or later proposing to add a second syntax.

--000000000000efb33505ad37686f--