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 <[email protected]>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 > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
