Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110604
MIME-Version: 1.0
References: <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>
 <BYAPR05MB653531BBEA5D8DEBE882DC64DE9D0@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB653531BBEA5D8DEBE882DC64DE9D0@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Tue, 16 Jun 2020 15:18:17 -0300
Message-ID: <CAOsHV+vATNgqVq9uro+q1-fzoqUAWZN_A_9YrAKtSEZR9z1CsA@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000002da205a83792a7"
Subject: Re: [PHP-DEV] Re: [RFC] Shorter attribute syntax
From: marcio.web2@gmail.com (Marcio Almada)

--000000000000002da205a83792a7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,


> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback completed an RFC proposing to use the shorter `@@` syntax
> > instead of `<<>>` for attributes in PHP 8.
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> >
> > The goal is not to bikeshed over subjective syntax preferences,
> > but to address several concrete shortcomings related to verbosity,
> > nested attributes, confusion with generics and other tokens, and
> > dissimilarity to other common languages.
>
> Just a heads up that the two week minimum discussion period expires
> tomorrow, and I'm planning to open voting soon.
>
>
Hi! Thanks for the notification. I'll probably vote for the `@@` syntax for
three reasons:

- It feels similar with at least other 5 or 6 languages that choose `@` as
their attribute sigil;

- The lack of closing brackets make it less verbose, both on nesting and
non nesting cases;

- BC breaking the stacking of the error suppression operator as in
`@@@@some_call()`
actually makes some sense. AFAIK there was no reason to allow it, and maybe
it was just
an implementation oversight? So if the new proposal comes with this nice
"fix" attached,
at least it feels like a fix to me, it's two good changes on the same
package. If not I'd
propose to disallow `@@@...` combos myself separately if there is time to
do so.


> Best regards,
> Theodore
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Thank you for your work.

Cheers,
M=C3=A1rcio

--000000000000002da205a83792a7--