On Mon, Aug 17, 2020, at 7:30 AM, Michael Voříšek - ČVUT FEL wrote:
> > 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
>
> 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.
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 needing to
do extra work as well. Minimizing work for 3rd party parsers is one of the
main goals under discussion, as I understand it. I'm not sure it's viable,
therefore, much as it does have its appeal conceptually.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
