Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111373
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>
 <CAEPJdu=f8q_igN5LNGvOhnyPwNvCazqfsehZ6Dg6g40pWu_J_g@mail.gmail.com> <BYAPR05MB653568CD28BDC009D7D1C48EDE490@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB653568CD28BDC009D7D1C48EDE490@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Sat, 8 Aug 2020 11:35:03 +0300
Message-ID: <CANeKSiRCBzUfLG1tfhtv+fz7Y9PECVgW0YkgJXMwEv1kMPA32w@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, Rowan Tommins <rowan.collins@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f09b3205ac599907"
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000f09b3205ac599907
Content-Type: text/plain; charset="UTF-8"

>
>
> This is some new complexity, even if only a small amount right now.
> My question remains about how much more added complexity it will
> require later if we implement extensions like nested attributes.
>

What? Are you actually saying that 30 lines of code add "complexity"? I
think you should look more at the PHP source code before going to these
nonsensical conclusions. PHP is a fully fledged language, not a "let's
write the shortest code possible" competition.

As for the nested attributes, you can implement those with simple
recursion. You are trying to create problems here that don't exist.


> Yes, PHP has historically been rather verbose in some ways.
> Thankfully this has been gradually changing, with the short array
> syntax added in 5.4, and more recently short arrow functions,
> constructor property promotion, and the match expression having an
> explicit goal to reduce verbosity.
>

No offense intended but saying that 1 extra character somehow adds
verbosity is quite honestly, one of the stupidest things I have heard.

While we at it, let's also rename other keywords: `function` to `f`,
`while` to `w` and `static` to `s`. You know, to save those few extra
characters.


> What is the goal of the grouped attribute construct? I still haven't
> received an answer about what makes it better than `@@`.
>

You can't compare attribute syntax against attribute feature. You better
tell me why `@@` is better than `@[]` using arguments and not with "boo, I
have to type 1 extra character with `@[]`".

As for the grouped attributes. Why do we allow grouped properties and class
constants? It's alternative code style that some might prefer.

>

> Aren't docblock annotations only wrapped in /** */ because they have to
>
be inside a comment? There is no need for this with the native
> attribute syntax. To me, the `#[]` and `@[]` tokens don't at all look
> similar to docblock comment boundaries, anyway.
>

Even more so with `@@`, which look nothing alike to docblocks. Just because
docblock annotations contain the same character as attribute syntax, it
doesn't magically mean "it's like docblocks". Because if so, `@[]` looks
far far more like docblocks than `@@`.


> Best regards,
> Theodore


Best regards,
Benas

--000000000000f09b3205ac599907--