Re: [RFC] Shorter attribute syntax

On Thu, June 4, 2020 at 12:19 PM Rowan Tommins <rowan.collins@gmail.com> wrote: > Hi Theodore, Hi Rowan, Thanks for the feedback. I added replies inline. > I find the "objective" reasons in this RFC to be greatly exaggerated. > > 1. @@Jit does not require "half as many characters" > as <<Jit>>; > even for this, which is probably the shortest attribute anyone will > ever use, the saving is less than 30%; for more common attributes > which resemble entire function calls, it will be a tiny proportional > saving. By "half as many characters" the RFC is referring to the attribute syntax itself, not the name/arguments of the attribute being used. You're right that with longer attributes, the attribute syntax makes up a smaller percentage of the code. However, I'd argue the savings still has value even when it's a smaller proportion. > 2. You don't actually explain why @@Foo would be any > easier to > integrate with nested attributes than <<Foo>>. Is > there some > parser conflict that applies to one and not the other? Martin can correct me if I'm wrong here, but I believe nested attributes are syntactically possible with the <<>> syntax, but "ugly as sin" (to quote Nikita). For example: ```php <<JoinTable( "User_Group", <<JoinColumn("User_id", "id")>>, <<JoinColumn("Group_id", "id")>>, )>> private $groups; ``` Also, grouped attributes would probably have to be special-cased to be disallowed in nested attributes, since they don't make sense there. During implementation a bunch of work was put into trying to support nested attributes with new (e.g. new JoinColumn("User_id", "id")), but as the RFC mentions this was given up on since it turned out to be very difficult to implement and would require lots of changes to const expressions. > 3. While confusion with generics is possible, I would be interested > to hear from C# programmers how often they confuse [Attribute] > for > an array index operation, or any of the other uses of square brackets. One reason I think confusion with generics is more probable is that generics and attributes would frequently be used in a similar location (near the start of a class declaration). > 4. Similarly, I've yet to see anyone point to an example of confusion > with shift operators that's not extremely contrived. I could come up > with equally contrived examples where an attribute contained e-mail > addresses and twitter handles, making @@ look confusing. Perhaps, though this seems much less likely since email addresses and twitter handles would be in a string, whereas << is a standalone token used outside of strings. > 5. No other language has been put forward using the @@ > operator. It > more closely resembles those languages that use a single @, but > the > <<Foo>> syntax more closely resembles those > languages that use some > form of brackets. Fair enough. This doesn't really seem like an argument one way or another. > I also find it disingenuous that you refer to the > <<Foo>> syntax as > "the shift tokens" throughout, but do not similarly call your proposed > syntax "the double-suppression token". If one is "double-at", then the > other is "double-angle-brackets". I don't understand how it's disingenuous. The RFC refers to the shift tokens as such because that's what they are (T_SL and T_SR). The proposed @@ syntax uses a new T_ATTRIBUTE token. > The one convincing *objective* argument I've seen is Jordi's, that > @@ would be easily greppable. Interestingly, that's not > true of > any of the other languages listed in the comparison other than Rust's > hash-bracket and maybe C++'s double-bracket, but that doesn't mean we > can't do better. Yes, I this is one reason I think having an @@ token is a good fit for PHP, as preserving easy greppability has influenced other syntax decisions as well (e.g. the placement of return types). > Other than that, I think it really comes down to a matter of taste. Some > people reacted to the <<Foo>> syntax the way they > did to the Cats movie > trailer, and may react to this one better. That's fine; we can make a > decision for subjective reasons, but let's be honest and say that. Well, I guess the line between objective and subjective may sometimes be a bit subjective. :) Best regards, Theodore