Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111437
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008100935570.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB653523B03F0BFCCCCB01796ADE440@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB653523B03F0BFCCCCB01796ADE440@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Mon, 10 Aug 2020 17:02:08 +0300
Message-ID: <CANeKSiQpuQht-zY_E5T7+kK74u5+H346DgMsZHD2vH45+U-+Ow@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003b7d5505ac866786"
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: benas.molis.iml@gmail.com (Benas IML)

--0000000000003b7d5505ac866786
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 10, 2020, 4:28 PM Theodore Brown <theodorejb@outlook.com> wrote:

> On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans <derick@php.net> wrote:
>
> > I've just opened the vote to make sure we don't make a terrible mistake
> > with using the @@ syntax for attributes:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
> >
> > The first vote is a vote to say that you have an opinion about attribute
> > syntax. Make sure to read up on the discussion on the mailinglist if you
> > haven't done so yet.
>
> I voted "No", as the primary premise for this RFC is fundamentally flawed:
>
> > The main concern is that @@ has no ending symbol and it's inconsistent
> > with the language that it would be the only declaration or statement
> > in the whole language that has no ending termination symbol.
>
> As I pointed out in the discussion thread, this simply is not the case.
> Attributes are not standalone declarations or statements, but modifiers
> that always come before a declaration and add metadata to it. This
> is consistent with visibility modifiers and type declarations (which
> are not necessarily a single word):
>
>     # declaration modifiers do not have end/grouping symbols like this
>     @[MyAttr([1, 2])]
>     [public] function foo(@[Deprecated] [int|float] $bar) {}
>
>     # this is more consistent:
>
>     @@MyAttr([1, 2])
>     public function foo(@@Deprecated int|float $bar) {}
>
> > The second vote is an STV vote.
> >
> > In STV you SHOULD rank *all* choices, but don't pick the same one more
> > than once, as that will invalidate your vote.
> >
> > Please have a objective look at the table
> > (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> > don't just go by asthetics.
>
> I find this table to be unfortunately incomplete. E.g. why doesn't it
> bold the number of required characters for @@, since this is one of
> its advantages? And


IMO there's literally no advantage in typing one less character. Because if
there is, let's also shorten all of our function names i. e. `strlen` to
`sl` and `gettype` to `gt`.

why is "Allows Grouping" marked as an advantage
> for the other three syntaxes? Grouping adds implementation complexity,
> leads to unnecessary diff noise, and is rarely more concise than @@ in
> real-world use cases.
>

I'd like to remind other internals that there is no "added complexity"
(unless someone is unable to understand 20 lines of code) and it's
misleading to say otherwise.


> I also find it concerning that the RFC doesn't have an example for each
> consideration showing how one syntax addresses it better than another.
> For example, the Shorter Attribute Syntax RFC showed potential nested
> attributes and how @@ would support them more cleanly, but this RFC
> fails to mention them anywhere.


Syntax choice DOES NOT affect how "cleanly" we can support nested
attributes. AFAIK simple recursion would allow to implement those with any
attribute syntax with exactly the same code.


> Finally, while the table mentions that each syntax other than <<>> has
> a BC break, I think it's just as important to consider the *size* of
> the breaking change. #[] and @[] are larger BC breaks than @@ since
> they break useful syntax:
>
>     // with #[]
>     #[x] code like this would break
>     $val = ['new value']; #['old value'];
>
>     // with @[]
>     $x = @[foo(), bar()]; // this code would break
>
> Both of these are useful patterns, and I'm not convinced that breaking
> them is justified. Shouldn't there be a Backward Incompatible Changes
> section in the RFC with these examples?
>
> Best regards,
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000003b7d5505ac866786--