Allen Wirfs-Brock schrieb:
>
> On Dec 16, 2014, at 1:18 PM, Bergi wrote:
>> ...
>>
>> I've read <https://esdiscuss.org/topic/referencing-super> and it seems that needing to call `super.describe()`/`super.render()`/`super.say()` is intended behaviour. I'm fine with that, as explicit is better than implicit and "finding the method with the same *name*" (or something like that) is overly complicated and maybe even ambiguous.
>
> Yes, this is a fairly recent change to the ES6 draft specification. People who write public commentary and tutorials about ES6 need to keep up with evolving spec changes.

Sure they do, but I didn't even know that there was an earlier revision 
where this had once worked. Thanks for the clarification!

>> However, it seems that we need to communicate better that `super()` calls only work in constructors, and other functions that inherit from functions (<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-getsuperconstructor>).
> Rev 29 made `new super` and `new super ( )` early errors in non-constructor concise methods.

Ah, 
<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-initializer-static-semantics-early-errors> 
and 
<http://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions-static-semantics-early-errors>. 
I had not seen that.

It might be nice if there was a note about these in the Static Semantics 
for the `super` keyword productions 
(http://people.mozilla.org/~jorendorff/es6-draft.html#sec-super-keyword-static-semantics-early-errors)

 > It doesn't do the same thing for `super( )` calls that appears to be 
an editorial mistake that I will correct in Rev 30.

Thanks!

>> Should an exception been thrown if the `func` returned by `GetSuperConstructor()` is `%FunctionPrototype%`?
>
> It it [[Prototype]] was set ot %FunctionPrototype% from a different realm?
>
> I think the early error described above is a better solution as it address the syntactic context of the usage rather than actual runtime value.

Yes indeed. This will fit the needs of the majority who *declare* their 
methods in object literals or classes much better than a runtime 
exception (which was just the first idea that had come to my mind). And 
we probably don't need to care about those who manually assign functions 
and call `.toMethod()` etc.

However, I wonder whether the same thing should be done in non-concise 
method assignments, i.e. `PropertyDefinition : PropertyName : 
AssignmentExpression`. As the `PropertyDefinitionEvaluation` handles the 
"IsFunctionDefinition of AssignmentExpression" case specially, I think 
the static semantics for it should do so as well (and forbid `super` 
calls in them).

  Bergi

Allen Wirfs-Brock schrieb:

> Yes, this is a fairly recent change to the ES6 draft specification. People who write public commentary and tutorials about ES6 need to keep up with evolving spec changes.

Sure they do, but I didn't even know that there was an earlier revision 
where this had once worked. Thanks for the clarification!

> Rev 29 made `new super` and `new super ( )` early errors in non-constructor concise methods.

Ah, http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-initializer-static-semantics-early-errors and http://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions-static-semantics-early-errors. 

I had not seen that.

It might be nice if there was a note about these in the Static Semantics 
for the `super` keyword productions 
(http://people.mozilla.org/~jorendorff/es6-draft.html#sec-super-keyword-static-semantics-early-errors)

 > It doesn't do the same thing for `super( )` calls that appears to be an editorial mistake that I will correct in Rev 30.

Thanks!

> I think the early error described above is a better solution as it address the syntactic context of the usage rather than actual runtime value.

Yes indeed. This will fit the needs of the majority who *declare* their 
methods in object literals or classes much better than a runtime 
exception (which was just the first idea that had come to my mind). And 
we probably don't need to care about those who manually assign functions 
and call `.toMethod()` etc.

However, I wonder whether the same thing should be done in non-concise 
method assignments, i.e. `PropertyDefinition : PropertyName : 
AssignmentExpression`. As the `PropertyDefinitionEvaluation` handles the 
"IsFunctionDefinition of AssignmentExpression" case specially, I think 
the static semantics for it should do so as well (and forbid `super` 
calls in them).