Allen Wirfs-Brock wrote:
> Yep -- I'm warming up to LeftHandSideExpression. It allows new and call
forms, member expressions, primary expressions, but not unparenthesized ternary,
binary or unary operators -- and (crucially for the bug) not anything ending in
AssignmentExpression. Allen?
>
Playing devil's advocate for the movement. Sure, general Expression
You must mean AssignmentExpression -- no ES6 draft allows comma
expressions after extends.
allows for odd and probably useless things in an extends clause but so does a
ParenthesisedExpression so it isn't clear that the LHSExpression restriction
really gives JS programmers anything if there is some other way to fix the
yield bug. But what the LHSExpression restriction does do is make the language
conceptually more complex for programmers.
No, "for programmers" is not an abstract claim you can make based on
grammar details, it depends on what "most programmers" expect and
*actually use*. Class head syntax for most programmers is not considered
a place to put arbitrary expressions, e.g., involving && or * / % or
unary+/-.
The idea that programmers will face complexity in not being able to write
class MyWidget extends objWithValueOf + haha { ... }
and instead have to write
class MyWidget extends (objWithValueOf + haha) { ... }
is silly. Hardly any programmers, in the first place, will write any
ternary, binary, or unary operator expression after extends.
The tiny fraction who might write such code would need parentheses.
That's a good thing, for readability, IMHO.
Currently Statement and Declaration forms consistently only use Expression or
AssignmentExpression as component elements.
The extends clause's RHS is not a "component element".
And, AssignmentExpression (with one exception, which I think may be a bug.
separate issue...) is only used in contexts where there would be a comma based
ambiguity. So, taking the language as it stands now, there is really only one
concept of expression that JS programmers have to learn and think about when
composing JS statements.
You are inverting how programmers write code. They do not think "what
does the grammar generally allow?" and then write the widest form that
parses.
Restricting the expression in the extends clause of a class definition to
LeftHandSideExpression would mean that there is another "top-level" expression
form that is used somewhere in the statement grammar. It's quite likely that some JS
programmer will be taught about this but only remember that most places you can use a
general expression but some places you can only use some restricted expression form. For
that point forward, they may be questioning themselves anytime they write an expression:
Is this a place where I have to restrict which operators I use?
It's quite likely? Evidence?
If we go that route we are trading-off conceptual simplicity against some
grammar complexity that most programmer will never see and that only only
restricts the YieldExpressions syntax in a manner and place that nobody
probably will ever encounter. While it would need to be documented in
reference material, no one would really need to be taught about the yield value
expression being required in extends clauses.
No, see below.
Finally, turns out that restricting the optional yield AssignmentExpression
only requires additional parameterization of three productions: Expression,
AssignmentExpression, and ConditinalExpression.
That's enough to be a minor blight, and worse, you are now forbidding
someone from writing a class declaration *or expression* in a generator,
and using yield to send a value in as the base class to extend. Why?
So, from a conceptual simplicity and consistency perspective, I think it may be
better to go with alternative #3 (require AssignmentExpression in
YieldExpressions in extends clauses).
You argument from expected grammar is backwards and doesn't make sense.
Meanwhile, a send into a
yield class extends (yield) { ... }
in a generator would be denied for no good reason. And you've crudded up
the grammar with a parameterized check that is not otherwise needed.
I think it's time for the devil to yield, no pun intended.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
