Hi Rowan, On Sat, June 6, 2020 at 7:06 AM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> The `::` token in the parser is called `T_PAAMAYIM_NEKUDOTAYIM`, and > personally I find `T_SL` and `T_SR` just as cryptic and irrelevant. The most > common place I see those token names is when accidentally running code > with conflict markers like "<<<<<<<<", or when messing up heredoc > syntax; even if they weren't so abbreviated, my reaction would be "shift > what now?" I've used bit-shifts maybe twice in the last ten years, so > it's just not an immediate association to me. > > "Disingenuous" was probably too strong a word, but I do think it relates > to a fundamental difference in viewpoint: to some people, `<<` and `>>` > are first and foremost the shift-left and shift-right operators, and so > the immediate association on seeing them is so obvious it's not worth > mentioning; to others, they just look like a new kind of brackets. > > That association might actually be a good reason to avoid that syntax, > but if so it should be spelled out, rather than taken as a given. That makes sense. I updated the RFC now to avoid usage of "shift tokens" in most places and instead refer to them as `<<` and `>>` tokens. I also added a sentence spelling out why the association with shift operators may be confusing for some developers. Additionally, the RFC more clearly lays out the issues with nested attributes now. > > Also, grouped attributes would probably have to be special-cased to > > be disallowed in nested attributes, since they don't make sense there. > > I'm not entirely clear how they work in current implementations like > Doctrine's, but I think nested attributes would have to have completely > different rules anyway, because you don't access them directly through > reflection in the same way. > > If `<<Foo( <<Bar>> )>>` means something like `new Foo( new Bar )`, then I > can imagine it being useful for `<<Foo( <<Bar, Baz>> )>>` to mean > `new Foo( [new Bar, new Baz] )`. That would actually be more convenient than > the double-at version, where you'd have to write `@@Foo( [@@Bar, @@Baz] )` > or use a constructor with a `...$variadic` parameter. In that example there are the same number of characters either way, so it's not clear the nested `<<>>` approach would be more convenient. And do you think it's a good idea to have an additional syntax for creating arrays like that? It seems like it could get confusing. > Ultimately, it all comes down to judgement calls - is the > double-angle-bracket syntax "too verbose", "too ugly" when nested, etc; > and does the double-at syntax make it "better enough". Yes, I agree that there's a judgment call to make. Out of curiosity, given these shortcomings of the double-angle-bracket syntax, do you think there are any objective reasons to prefer it over `@@` (other than the theoretical BC break of code like `@@@really_suppress_me()`)? Best regards, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
