On Mon, June 8, 2020 at 10:01 AM Larry Garfield <la...@garfieldtech.com> wrote:
> FWIW, I find both alternatives ugly to my eye. So, there's that.
>
> Given that `@` is off the table for obvious reasons, my preference
> would frankly be for Rust's `#[]`, which has the nice side effect
> of being a normal comment in earlier PHP versions and so attributes
> can be included as optional without breaking BC. I don't know if
> that's a big deal or not, but it's a benefit. And it should be no
> harder on the parser to differentiate than `@` vs `@@` is.
>
> (The only advantage of `@@` in my mind is another obvious Star Wars
> joke.)
Hi Larry,
>From the perspective of looks I don't have a strong preference
between them. There are two main reasons I decided against borrowing
the `#[]` syntax from Rust:
1. It's a much larger BC break. Disallowing comments from starting
with a certain character could break a lot of code in the wild.
>From a quick search of grep.app, I found two examples on the first
page of results using `#[` as a comment. [1] Is it worth breaking
this code?
2. `#[]` is slightly more verbose, which works against one of the
objectives of the RFC. Rust is the only language I found that uses
three characters for its attribute syntax like this.
I actually starting trying to draft an RFC which would propose the
`#[]` syntax for attributes, but one thing I noticed while doing
so is that (at least on my QWERTY keyboard) `#[` is noticeably
harder to type - I kept typoing it as `#]` or `#\`. This is dependent
on keyboard layout, of course, but being prone to accidental typos
was also one of the arguments against the `@:` syntax in the original
RFC.
> Something that I don't think has been addressed explicitly in this
> thread yet is single line vs separate line attributes. Vis:
>
> `<<Foo>> class Blah {}`
>
> vs.
>
> ```php
> <<Foo>>
> class Blah {}
> ```
>
> Syntactically both are legal AFAIK; I don't know which most people
> will do. The separate line version seems more likely, and cleaner
> to me, but for parameters people may want to inline it in shorter
> signatures. Or it may push people to always multi-line those
> function definitions, for better or worse. (I find that quite ugly
> myself, but I don't know if I'm in the majority on that view.)
>
> My gut feeling is that `@@` is notably worse inline. It subjectively
> feels messier because there's no clear indication of where the end
> is. On separate lines, `@@` and `<< >>` seem about equally ugly to me.
Personally I have the opposite reaction when it comes to inline
parameter attributes - the closing `>>` always looks like a shift
operator at first glance which makes it harder for me to read. And
for an inline function or class attribute the function/class keyword
already provides a strong indication of where the attribute ends.
But for anything other than very short attributes, I expect most
people will want to put the attribute on a separate line for optimal
readability, regardless of the final syntax:
```php
function foo(
<<ExampleAttribute("foo", "bar")>>
<<OtherAttribute(123, ["key" => "val"])>>
Type $myParam,
bool $param2,
) {
...
}
// vs.
function foo(
@@ExampleAttribute("foo", "bar")
@@OtherAttribute(123, ["key" => "val"])
Type $myParam,
bool $param2,
) {
...
}
```
Best regards,
Theodore
[1]: https://grep.app/search?q=%23%5B&filter[lang][0]=PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
