Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111365
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB6535AE9831221566469C4503DE4A0@BYAPR05MB6535.namprd05.prod.outlook.com>
 <alpine.DEB.2.23.453.2008060741110.7489@singlemalt.home.derickrethans.nl>
 <20200806091749.64675445@mcmic-probook.opensides.be> <CANeKSiStbGZG+EOVDRfRuVo4MA7th16R-oP7V2xmPj3xHNxs_A@mail.gmail.com>
 <CALKiJKporEo8DitTBqom=u0onqwQU+MiWF45R61cGHXzU783Fw@mail.gmail.com>
 <CANeKSiRivtUWsH8ySYVtjmz3JX8mrs-OJLEin_2V+A7xt18X+A@mail.gmail.com>
 <BYAPR05MB65357345667E6A35EDD89025DE480@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CANeKSiSFJPmrtLcuxtPh7Sov21JNJTe3SMrS4WzJa_ZCVkcViw@mail.gmail.com> <BYAPR05MB6535BD371D9084AF7C16A9B6DE480@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB6535BD371D9084AF7C16A9B6DE480@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Fri, 7 Aug 2020 10:32:15 +0200
Message-ID: <CAEPJdu=f8q_igN5LNGvOhnyPwNvCazqfsehZ6Dg6g40pWu_J_g@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: Benas IML <benas.molis.iml@gmail.com>, Rowan Tommins <rowan.collins@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f2725605ac4571a1"
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000f2725605ac4571a1
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown <theodorejb@outlook.com>
wrote:

> On Thu, Aug 6, 2020 at 12:30 PM Benas IML <benas.molis.iml@gmail.com>
> wrote:
>
> > Hey Theodore,
> >
> > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown <theodorejb@outlook.com>
> wrote:
> >
> > > While none of our syntax options are perfect, I believe @@ has the
> > > best long-term tradeoffs because:
> > >
> > > - It doesn't break useful syntax
> >
> > Fair enough.
> >
> > > - It is equally or more concise than grouped attributes without
> > > adding complexity to the parser/compiler
> >
> > Are we really going to debate that ~30 lines of code add complexity?
>
> Hi Benas,
>
> I don't know how many lines of code it will be, since an
> implementation for it has never been finished. The patch currently
> linked in the RFC does not implement it.
>

Curious what brings you to claim an implementation has never been finished
when it was accepted by RFC vote?

Grouping certainly has a finished implementation, Martin and I had it
working for the original RFC, then when we removed it for the original vote
had a working patch and PR as part of the Amendments RFC.

I now ported the patch to the @[] syntax PR here:
https://github.com/php/php-src/pull/5928/commits/c69e2de26c42c583a8ca0fa579c1be69d40bfc454
The zend_compile.c diff looks a bit complex, but it's really only 5 new
lines for a new for loop over the groups and all existing code one level
deeper.

All in all the attribute grouping patch adds 26 new lines (and then tests)
all restricted within the existing attribute parser rules and the functions
compiling attribute code. This adds no complexity at all.


> Even if we assume the implementation is only about 30 lines, it's
> still extra complexity that I don't understand the benefit of. I
> sincerely would like to know what advantage there is of grouped
> attributes over the `@@` syntax.
>
> - It is equally or more verbose than `@@` in real-world use cases
>

You keep bringing up verbosity like our primary language design goal is to
reduce it, PHP is the most verbose language I know. Everything in PHP
requires more characters than in other languages. Keywords are usually
long, variables need an extra $ in front. You have
to use $this-> as no implicit context exists. Functions need to be prefixed
by "array_", "str_" instead of methods on the objects.

The primary design goal of a language construct in PHP is not to reduce
verbosity.


> - Adding or removing a second attribute with grouping can require
> modifying multiple lines, adding unnecessary noise to diffs:
>
>       @@SomeAttribute("value")
>       @@AnotherAttribute("value") # can be added/removed independently
>       function foo() {}
>
>       # vs.
>
>       @[SomeAttribute("value")] # changes to:
>
>       @[
>           SomeAttribute("value"),
>           AnotherAttribute("value"), # not added/removed independently
>       ]
>       function foo() {}
>

> - How much more added complexity will the grouped syntax require if
> we add nested attributes in the future? At the least it will have to
> be special-cased in some way, either to disallow grouping for nested
> attributes or to treat the grouped syntax the same as an array.
>
`@@` avoids the need for additional complexity, special cased syntax,
> and having to modify extra lines when adding/removing separate
> attributes.
>
> > > - It is conceptually closest to the docblock syntax the PHP
> > > community is familiar with
> >
> > Well, if `@@` is similar to `@` (to me it isn't), we can say that
> > `@[]` is also similar to `@`.
>
> I would agree that `@[]` is more similar than `#[]` is. But arguably
> `@@` is still the closest since docblock annotations don't require
> being wrapped in array brackets.


But docblocks are wrapped in /** */, enclosing the whole declaration of
them.

Both @[] and #[] are comparable with /** */ as metadata **boundary**. The
attribute
itself has no symbol prefixes or alike, it's just the class name.

This is a very close translation to how docblocks with userland doc-params
work,
in my opinion this makes all enclosed syntaxes much more in line with
existing syntax,
regardless of symbols used.


> > > - It is aligned with the attribute semantics of the majority of C
> > > family languages
> >
> > In what way `#[]` or `@[]` aren't?
>
> The majority of C family languages use `@Attr` without an extra end
> symbol. This makes sense since attributes are simply metadata
> modifying the declaration that follows them, similar to visibility
> and type declarations.
>
> Best regards,
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000f2725605ac4571a1--