On Fri, Aug 7, 2020 at 3:32 AM Benjamin Eberlei <kont...@beberlei.de> wrote:
> On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown <theodor...@outlook.com> wrote: > > On Thu, Aug 6, 2020 at 12:30 PM Benas IML <benas.molis....@gmail.com> > > > wrote: > > > > > Hey Theodore, > > > > > > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown <theodor...@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. Hi Benjamin, Apologies, I didn't realize the grouped attribute implementation was completely finished before. When it was dropped from the Attribute Amendments pull request, a bunch of other changes still had to be made before it was ready to merge, and I assumed that some changes would have also been required for attribute grouping. Thank you for the correction. > I now ported the patch to the @[] syntax PR here: [updated link] > https://github.com/php/php-src/pull/5928/commits/597688fd5b0a41d23028454b62ba25f950f35a16 > 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. 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. > > 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. 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. > The primary design goal of a language construct in PHP is not to > reduce verbosity. What is the goal of the grouped attribute construct? I still haven't received an answer about what makes it better than `@@`. > > `@@` 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. 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. Best regards, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
