Hi Rowan,
On Sun, June 7, 2020 at 5:32 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On 07/06/2020 19:37, Theodore Brown wrote:
> > 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()`)?
>
> I'm not convinced there's any objective reasons to be found either way,
> but for the sake of "playing devil's advocate", here are a few that
> could be put forward:
>
> If grouped attributes are added, they're actually slightly less verbose
> than repeating a double-at prefix, once you have enough attributes in
> the set:
>
> Minimum spacing and punctuation requires n+3 chars vs 3n, so a saving
> even with 2 attributes:
> `<<Foo,Bar>>class Bob{}`
> vs
> `@@Foo @@Bar class Bob{}`
>
> More realistic spacing is 2n+3 vs 3n, giving a saving only with 4 or more:
> `<<Foo, Bar, Baz, Quux>>class Bob{}`
> vs
> `@@Foo @@Bar @@Baz @@Quux class Bob{}`
Neither of these are realistic examples, though. In practice, you're
not going to have an empty class definition on the same line as a
bunch of short attributes like this. Based on the Use Cases section
of the Attributes v2 RFC, [1] typically there would be three or fewer
attributes applied to a given entity.
The RFC only has one example with four attributes, which happens to be
a flattened version of the nested attributes use case discussed in the
Shorter Attribute Syntax RFC. But in this example, the attributes each
have one or more parameters, which makes them long enough that they
have to be on separate lines. And with sane formatting, the `<<>>`
syntax version still ends up being more verbose:
```php
// 170 characters for attributes (162 not counting leading whitespace)
<<
ManyToMany(Phonenumber::class),
JoinTable("users_phonenumbers"),
JoinColumn("user_id", "id"),
InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE),
>>
private $phonenumbers;
// 160 characters for attributes
@@ManyToMany(Phonenumber::class)
@@JoinTable("users_phonenumbers")
@@JoinColumn("user_id", "id")
@@InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;
```
So the idea that the `<<>>` syntax with grouped attributes will be
less verbose than the `@@` syntax turns out not to be the case in
real-world use cases.
> Bracket-based syntaxes, particularly with grouping, are more clearly
> separated from the main code, particularly when used inline. For instance:
>
> `$f = @@Something @@AnotherThing function(@@Special @@ReallyInt int $var)
> {};`
> vs
> `$f = <<Something, AnotherThing>> function(<<Special, ReallyInt>> int $var)
> {};`
To me there doesn't seem to be a big difference in readability between
the function attributes in this example. And with syntax highlighting,
the function keyword itself provides a very clear separation.
For the parameter attributes, the `@@` syntax example is actually
more readable to my eye. I can't help seeing the `>>` token as a
shift operator at first glance in this context.
> Finally, typing up those examples, it occurs to me that `@@` is quite a
> "heavy" symbol - it has a large proportion of black (or whatever colour)
> pixels - and inevitably a rather "fussy" one. I find it draws the eye
> more than the angle-brackets do, which feels unfortunate.
I guess this is somewhat dependent on the font you're using. But in
general I don't think that the symbol being "heavy" is necessarily
a bad thing. It can help attributes stand out better from function
calls, generics, and other nearby syntax.
Best regards,
Theodore
[1]: https://wiki.php.net/rfc/attributes_v2#use_cases
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
