On Dec 3, 2013, at 11:28 AM, Andrea Giammarchi wrote: > trying to understand in order to update a polyfill != emotional attached to > mixin > > I find mixin useful for what it has always done until now (that is > temporarily gone and it is un-shimmable due this new toMethod entry for what > I can tell so it will likely not be adopted later on)
Object.mixin was always unshimmable because of the its super rebinding semantics. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-mixinproperties > > Still very looking forward for a concrete example where `super()` that points > to a different one after `toMethod()` is desired, thanks. The the last meeting we also decided to eliminate the comparator argument to the Map constructor because it only was useful for the case where you wanted to memoize -0. Here is a "mixin" object that can be used to selectively add that support to any Map instance to any Map subclass's prototype or to any object that exposes the Map interface: let MapM0 = (memo=> ({ has (key) { if (Object.is(key, -0.0) return memo.has(this); return super(key); }, get (key) { if (Object.is(key, -0.0) return memo.get(this); return super(key); }, set (key, value) { if (Object.is(key, -0.0) return memo.set(this, value); return super(key, value); } }))(new WeakMap); Just mixin (using toMethod, or your own implementation of Object.mixin) the properties of MapM0. Allen > > On Tue, Dec 3, 2013 at 11:21 AM, Domenic Denicola > <[email protected]> wrote: > I wish we'd never switched from Object.define to Object.mixin, since people > have such an emotional attachment to their conception of what the word > "mixin" means and it causes reactions like this. In that sense, I'm glad it's > gone from ES6. > > From: es-discuss <[email protected]> on behalf of Andrea > Giammarchi <[email protected]> > Sent: Tuesday, December 03, 2013 14:18 > To: Brendan Eich > Cc: [email protected] > Subject: Re: any toMethod() use case ? > > I am the author of one of those github `Object.mixin` "wannabe shim" and this > is why I'd like to know how crucial/relevant would this toMethod be for the > implementation because it's un-shimmable for what I can tell if not swapping > a global `super` reference at runtime per each wrapped method: a complete > no-go that TypeScript itself should never adopt in my opinion. > > Moreover, I believe mixins should not bring multiple inheritance but rather > enrich objects and if a mixin calls its parent, that should be the expected > parent no matter where the mixin has been used to enrich another object. > > This is why I am having some difficulty imaging a scenario where toMethod is > needed and still I haven't seen a code example that would reflect some > real-world scenario/case. > > I am just trying to understand and nothing else. Thanks for any example/piece > of code that shows why toMethod is needed/wanted/desired instead of > static/explicit super.method calls. > > > > On Tue, Dec 3, 2013 at 11:07 AM, Brendan Eich <[email protected]> wrote: > Andrea Giammarchi wrote: > Thanks Allen but you mentioned `Object.mixin` twice while this has been > abandoned > > No, deferred -- but why does ES6 status matter? You seem to be impeaching > toMethod not because it isn't useful, as Allen showed, but because something > that would need it if self-hosted (Object.mixin) isn't standardized in ES6 as > well. That doesn't make sense. If Object.mixin is in ES6, one use-case for > toMethod is already "done". > > Anyway, Object.mixin should be done on github and win adoption. Probably > libraries will do their own variations. They all need toMethod to cope with > super. > > /be > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
