>
> Adding class syntax as (mostly) sugar for the prototypal pattern does not
> obviously mean rejecting all unusual or exceptional variants possible in
> the prototypal pattern. I say let super be used even in class C{}'s
> constructor, and let return-from-constructor work without requiring
> [Symbol.create]. JS is dynamic.


An example where super can be used in class C { } would be if you use an
existing class descriptor to later create a specialized framework class out
of it. An existing framework may have an internal base class that their old
syntax automatically added. This could allow them a plumbing function to
turn class descriptions into framework specific classes.

class C { constructor() { super(); } };

Framework.registerComponentTypes({ 'C': C });

Either by using setPrototypeOf, or using toMethod on the constructor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131228/00e4420c/attachment.html>

> Adding class syntax as (mostly) sugar for the prototypal pattern does not
> obviously mean rejecting all unusual or exceptional variants possible in
> the prototypal pattern. I say let `super` be used even in `class C{}`'s
> constructor, and let return-from-constructor work without requiring
> `[Symbol.create]`. JS is dynamic.


An example where `super` can be used in `class C { }` would be if you use an
existing class descriptor to later create a specialized framework class out
of it. An existing framework may have an internal base class that their old
syntax automatically added. This could allow them a plumbing function to
turn class descriptions into framework specific classes.

```js
class C { constructor() { super(); } };

Framework.registerComponentTypes({ 'C': C });
```

Either by using `setPrototypeOf`, or using `toMethod` on the constructor.