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
