On Thu, June 4, 2020 at 12:19 PM Rowan Tommins <rowan.coll...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
