Re: [RFC] Shorter attribute syntax

Hi Rowan, On Sat, June 6, 2020 at 7:06 AM Rowan Tommins <rowan.collins@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