On Nov 11, 2013, at 12:51 AM, Brendan Eich wrote:
> 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.
Yes, my recollection is we wanted to leave open the possibility that comma in
the extends clause might, in the future, have special meaning.
>
>> 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.
No, I think you're missing the point. Of course, most programmers will never
even consider writhing anything more complex than a function call in the
extends clause. But the extra complexity of having restricted expression forms
in some places does add to the overall conceptual burden on programmers.
>
> 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?
Evidence to the contrary? I'll cite personal experience. I find that when I'm
using (particularly on a casual basis) a language with lots of rules,
exceptions, and inconsistencies that I'm frequently have thoughts like "is this
kind of expression allowed here?"
The concern isn't that when somebody needs to do something like:
class extends (isBinary? Float64Array : Array) {
that they will need to remember to use parenthesis. The concern is that
because this restriction exists it may cause them to think about whether they
need parenthesis many other places.
>
>> 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?
I'm not sure what you are saying. They only restriction I had in mind was that
the expression within the extends clause could not end with the keyword 'yield'.
You couldn't say:
class extends yield {constructor() {...
but instead would have to say
class extends (yield) {constructor() {...
or
class extends yield undefined {constructor() {...
>
>> 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.
see above, not what I'm saying.
>
> I think it's time for the devil to yield, no pun intended.
Actually, in the past I have suggested exactly such a LHSExpression
restriction in various places (including computed property keys and perhaps
even in the extends clause) and the committee push back was that such
restrictions were generally undesirable...
Allen
>
> /be
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
