Alan, after considering the [March 25th Declarative Alternative to toMethod
conversation](
https://github.com/tc39/tc39-notes/blob/master/es6/2015-03/mar-25.md#6iv-a-declarative-alternative-to-tomethod-allen-wirfs-brock),
it really seems like a dynamic `super` would solve the problems mentioned.
The extra syntaxes,
```js
let mixins = obj => obj mixin {...}; mixins(target);
mixin TextSupport {...}
class MyComponent extends EmberComponent with TextSupport {...}
function (super) foo (x, y) { ...super ...x ...y }
//etc
```
just seem like ways to work around the static `super` problem, introduce a
bunch of new syntax when it is completely not needed, and as mentioned in
that conversation:
> YK: want to avoid "harsh end of life" outcome for ES5-ish libraries.
which depicts the very fragmentation between ES5 and ES6 that I mentioned
previously, which will cause a paradigm fork where some libraries will be
targeted at ES5 features or ES6 features but not both when ideally the
libraries should work with both feature sets. It would be great for the
progress of the JavaScript language to be linear rather than forked (f.e.
concise methods and class methods should be just functions with dynamic
`super`s that can be manipulated just as we're used to in the pre-ES6 era).
If `super` were dynamic, then users of widely-adopted libraries like
Backbone would have huge benefits:
```js
let NewClass = SomeBackboneClass.extend({
someMethod() {
// ...
super.someMethod() // this would work!! It would be awesome for
existing code bases!!
}
})
```
That will currently fail for the same reason as why `Object.assign` fails:
because `HomeObject` is static.
Would you or someone please convince me that a dynamic `super` would be
overhead-costly and performance-killing enough to have it be static?
*/#!/*JoePea
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
