Allen,
  my concern is that if I borrow that method I still assume that
`Map.prototype.has` is what I expect.

This is an assumption I can give for granted once I
`Object.freeze(Map.prototype)` while I cannot do the same assumption once I
use `super.has` since I don't know what will happen ... I won't even know
if that instance has a super with a `has` method while I am sure
`Map.prototype.has` exists.

What Brandon wrote after is not a real-world use case for toMethod, rather
the justification for the only place it would be used or it has been
created for, the deferred `Object.mixin` so I am still not sold on why we
need a runtime/dynamic resolution for super and still I wonder how much
this will impact TypeScript logic and performance once transpiled.

I hope somebody from Microsoft will find a minute to share thoughts on this.

Best Regards







On Tue, Dec 3, 2013 at 12:52 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131203/2baeb2ff/attachment.html>

Allen,
  my concern is that if I borrow that method I still assume that
`Map.prototype.has` is what I expect.

This is an assumption I can give for granted once I
`Object.freeze(Map.prototype)` while I cannot do the same assumption once I
use `super.has` since I don't know what will happen ... I won't even know
if that instance has a super with a `has` method while I am sure
`Map.prototype.has` exists.

What Brandon wrote after is not a real-world use case for toMethod, rather
the justification for the only place it would be used or it has been
created for, the deferred `Object.mixin` so I am still not sold on why we
need a runtime/dynamic resolution for super and still I wonder how much
this will impact TypeScript logic and performance once transpiled.

I hope somebody from Microsoft will find a minute to share thoughts on this.