Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111457
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008100935570.7489@singlemalt.home.derickrethans.nl>
 <CABHuAWyyNQ-w8X458OCbQxX5WXLwABhFjv8sFEbwcw1YrG=rhw@mail.gmail.com> <009179f2-74fc-ba74-fc82-28708169e400@beccati.com>
In-Reply-To: <009179f2-74fc-ba74-fc82-28708169e400@beccati.com>
Date: Tue, 11 Aug 2020 12:50:24 +0100
Message-ID: <CABHuAWyUA4QSLBwdEBk5C1FQV9Y6iEVMeh+Kvmf18oEC-oV-ow@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e473b005ac98ada8"
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: t.carnage@gmail.com (Chris Riley)

--000000000000e473b005ac98ada8
Content-Type: text/plain; charset="UTF-8"

On Tue, 11 Aug 2020 at 12:40, Matteo Beccati <php@beccati.com> wrote:

> Hi,
>
> On 11/08/2020 12:10, Chris Riley wrote:
> > What is the expected behaviour of:
> >
> > @[Bar()];
> > class Foo {}
> >
> > That would appear to be valid code and for the difference of a single ;
> > does wildly different things, assuming there is a function Bar defined
> > somewhere. (and only by the fact that @ doesn't suppress fatal errors
> does
> > it not cause utter confusion if Bar isn't defined)
> I think an 'unexpected token ";"', which is what currently happens if
> you do the same with "@@" on current master, would still be an
> appropriate behaviour.
>
> FWIW, I haven't made up my mind yet and that's why I haven't cast my
> vote yet.
>
> I do agree with Chris here and I somehow mentally parse the above as
> "silencing an array containing a function call", which to me is bad
> enough to rule the syntax out. I would surely get used to it, if
> accepted, but that's how I feel now.
>
> Rust's #[] to me looks better, but I am still bothered by the fact that
> it can be used in a backwards compatible way, but not fully so
> (multi-line, syntax errors).
>
> And "@@" is super ugly, although I'm not bothered that much by its lack
> of ending delimiter, since most of the times longer attributes will
> still, albeit just visually, have some in the closing ")".
>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/


My concern wasn't so much of mentally parsing it as a silenced function
call in an array; more that PHP currently parses it that way. That example
becoming invalid code would be a reasonable option, but leaving it as valid
code just sets people up to spend ages hunting a "why is this annotation
not being applied to my class bug". (and before anyone says this won't
happen; I have spent hours in the past tracking down missing annotations
which occured because of the difference between /* and /**)

For the record, my preference is @[ ], I just also like removing as many
potential cases of debugging stupid issues as possible.

~C

--000000000000e473b005ac98ada8--