> On Mar 10, 2020, at 6:54 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>> and fear — have trained many newbies in programming — that it will cause
>> newbies who see PHP to think it is too complex for them to consider
>> learning.
>
> I think the *concept* of attributes carries a much higher risk of that than
> any particular syntax. The same is true of things like generators, or
> traits, which use a more verbose syntax, but take a while to grasp.
But if we include attributes, then that point is moot. And orthogonal to the
syntax concern.
>> You mention that the good symbols are taken, but why limit ourselves to
>> symbols? Why not use words like PHP uses for other parts of the language?
>
> I guess the same question can be asked of any sigils and operators - why do
> we write "$foo->bar($a)" rather than "on foo call $bar with $a"? In the
> end, there's a trade-off: too many symbols become hard to remember, and
> hard to read close together; too many keywords become hard to read at a
> glance, and tedious to write.
Easy. Attributes are declarations. $foo->bar($a) is a runtime statement.
Developer write at least an order of magnitude more runtime statements than
declarations, so it makes sense that terseness would be a virtue for runtime
statements. The same is not true for declarations.
>> Alternately, why not use this (which is probably the best option IMO)?:
>>
>> function foo() attributes
>> SingleArgument("Hello"),
>> Another\SingleArgument("World"),
>> \My\Attributes\FewArguments("foo", "bar") {}
>>
>
> This particular example leads to complications with how different keywords
> stack up; would the return statement come before the "attributes" keyword?
How does the return statement affect this example? The return statement would
be inside the braces, the attributes would be before the braces.
Are you getting confused because I wrote an empty function body? I did so
because I was mirroring the RFC which used the same convention.
> if attributes were allowed on anonymous functions, would they come before
> or after the use () clause?
Why would we need to force an order? Let them come in either order.
(One of my biggest pet peeves about SQL is that the keywords have a defined
order that you cannot change, and there is no reason they need to do that
anymore with the power of today's computers and parsers.)
> The traditional placement above the declaration
> line keeps attributes out of the way of the main information about the
> function.
Yes, and I provided several examples of using keywords that keep attributes
"out of the way of the main information" too.
> It's also worth noting that all the other languages referenced in the RFC
> use punctuation, rather than keywords, for their equivalent functionality:
>
> C#: [Foo]
> Rust: #![Foo] or #[Foo]cont
> C++: [[Foo]]
> Java: @Foo
> ECMAScript (proposed): @Foo
> Go: `Foo` or "Foo"
> Doctrine et al: /** @Foo */
> Hack: <<Foo>>
@Foo is the only one of those that does not come across as syntax salad. And
[Foo] is not horrible. But as the RFC said, those are not possible.
That leaves C++, Rust, and Hack. Not exactly languages that somebody can
master without a ton of development skill.
Speaking of consistency, we don't use sigils for named classes. We don't use
sigils for properties. We don't use sigils for traits. We don't use sigils for
interfaces. Why should we use sigils for attributes? Just because other
languages did it that way? That seems like it is just a bandwagon
justification, not a justification based on evaluation of available options.
So I assert again, <<Foo>> is not a great syntax for userland PHP when we could
use a keyword-based syntax.
Point of note, Go does not actually have attributes/annotations. At best they
have the equivalent of structured PHPDoc:
https://stackoverflow.com/a/35205657/102699
> That doesn't mean PHP couldn't buck the trend and use a keyword instead,
> but we'd need a strong reason to do so.
Clarity? Readability? Ease of learning? Consistency with other declarations in
PHP?
Anyway, that's about all I think I'm going to say on this subject. But if
someone else has opinions on the topic, go for it.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
