super() call in methods
allen at wirfs-brock.com
Tue Dec 16 15:31:42 PST 2014
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.
> 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>). That seems to be the reason why the method name GetSuper*Constructor*() was chosen in the spec.
Rev 29 made `new super` and `new super ( )` early errors in non-constructor concise methods. It doesn't do the same thing for `super( )` calls that appears to be an editorial mistake that I will correct in Rev 30.
> Yet, `super()` calls in plain methods would actually work! The method objects would inherit from `Function.prototype`, which is itself callable: a no-op function. This might lead to subtle bugs, where `super()` was intended to call the parent class's method, but does nothing - not even throwing an error!
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss