Allen Wirfs-Brock (2013-12-03T20:52:06.000Z)
On Dec 3, 2013, at 12:10 PM, Andrea Giammarchi wrote:

> Thanks Allen,
>     however you know which super will be and what that operation does once invoked, right? Isn't toMethod bringing scenarios where you don't know what that would do?
> 
> Isn't that mixin unusable for any other kind of object that is not inheriting Map? The latter is the one that I don't get ... I can use toMethod for something that will simply break or not behave as expected, while what I'd like to do is to be sure that the Map method is used and nothing else.

Nope.  There is absolutely no dependency upon Map in the code I wrote.  Each of the methods  I showed have a dependency upon finding a like-named property up the prototype chain of the object it gets bound to (via toMethod) and implicitly assumes such properties correctly implement appropriate map-like behavior.  They do not depend upon finding Map.prototype on that prototype chain or upon finding the built-in implementation of the corresponding methods. 

These assumptions are no more risky then the assumptions I would have been making if instead of a super call I had coded:
      return Map.prototype.has.call(this, key);

When I code that I assume that, at runtime, a 'has' property will be found on Map.prototype, that the value of that property is a function, and that the function implements that contract that I'm expecting.  Saying super(key) or even super.has(key) makes the same assumptions but is not tied to any one particular inheritance hierarchy. 

Allen
domenic at domenicdenicola.com (2013-12-10T01:33:43.167Z)
Nope.  There is absolutely no dependency upon Map in the code I wrote.  Each of the methods  I showed have a dependency upon finding a like-named property up the prototype chain of the object it gets bound to (via toMethod) and implicitly assumes such properties correctly implement appropriate map-like behavior.  They do not depend upon finding Map.prototype on that prototype chain or upon finding the built-in implementation of the corresponding methods. 

These assumptions are no more risky then the assumptions I would have been making if instead of a super call I had coded:

```js
return Map.prototype.has.call(this, key);
```

When I code that I assume that, at runtime, a 'has' property will be found on Map.prototype, that the value of that property is a function, and that the function implements that contract that I'm expecting.  Saying super(key) or even super.has(key) makes the same assumptions but is not tied to any one particular inheritance hierarchy.