> On Jul 28, 2020, at 14:15, Ben Ramsey <b...@benramsey.com> wrote: > >> On Jul 28, 2020, at 14:10, Paul M. Jones <pmjo...@pmjones.io> wrote: >> >>> On Jul 28, 2020, at 14:07, Ben Ramsey <b...@benramsey.com> wrote: >>> >>>> On Jul 28, 2020, at 13:55, Paul M. Jones <pmjo...@pmjones.io> wrote: >>>> >>>> Now, it may be that #[] or <<>> or something else actually is "better" in >>>> some sense that cannot be articulated. But if there are no existing >>>> technical hurdles to be overcome with the already-voted-on-and-accepted >>>> solution of @@, what technically compelling reason can there be to revote? >>> >>> >>> IMO, there is no compelling reason to revote other than the fact that we >>> have no process for what to do in this situation. >> >> What "situation" is this, exactly? AFICT we have a working implementation >> using @@, with no technical hurdles to surmount. Or have I missed something >> that now prevents @@ from working per its RFC? > > > The new RFC outlines reasons why `@@` is a sub-optimal choice.
And yet it was the one chosen by the voting process. (Silly voters, making sub-optimal choices!) The rest of your message reveals what I thought was true: i.e., there are no currently-verified technical barriers to @@. To wit: > * current parser conflict (which can be worked around) AFAICT that pre-existing problem has been fixed, so this is a non-issue. > * possibility for further (as of yet unknown) parsing issues IOW, imaginary issues, aka FUD. > * a closing ] makes it easier to extend Attributes with more syntax, and at > the same time not be at the risk of running into parser conflicts Maybe, maybe not. This has the strongest possibility of becoming a technical argument, but no competing implementation (with a comparative implementation using @@) has been presented as an example. So as it stands now, this also is imaginary. > * userland analysis tools have difficulties parsing `@@` Though it does not seem insurmountable for those userland authors. Also, this is an interesting take: does Internals now defer to userland? If so, maybe it's time to open up voting more widely, so that the whole of userland can be represented more effectively here. Again, I don't especially care if @@, <<>>, or #[], or something else makes it through. Annotations of some sort seem like a nice idea, and I think they'd be of benefit. But if we are to make decisions by what is ostensibly a democratic process, we should stick to the voted decisions, instead of re-voting issues until the voters "get it right" according to some implicit and unstated criteria. (If re-voting over and over is the plan, I've got some RFCs I might like to revisit as well.) -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
