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 <domenic at domenicdenicola.com> 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 <es-discuss-bounces at mozilla.org> on behalf of Andrea Giammarchi <andrea.giammarchi at gmail.com>
> Sent: Tuesday, December 03, 2013 14:18
> To: Brendan Eich
> Cc: es-discuss at mozilla.org
> 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 <brendan at mozilla.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131203/f271f5a3/attachment-0001.html>

On Dec 3, 2013, at 11:28 AM, Andrea Giammarchi wrote:

> 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:

```js
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.