This is sort of OT but not too much. I have a concern about how mixins will be implemented in ES. It concerns clashing property identifiers in mixins and the classes taking their behavior.
By way of a simple example an Emitter could have a local property "this.listeners" for its own internal purposes. Likewise a class that mixes in Emitter could also have a local property "this.listeners". I was wondering if the delayed Object.mixin implementation included some sort of sandboxing to deal with this case or if it was left to the discretion of the developer? I guess the obvious suggestion is to use Symbols in Emitters, does this mean sandboxing will not be a consideration for Object.mixin? You could imagine a new version of the Emitter introducing a new identifier that could clash and lead to tricky bugs especially if the mixin did not define the identifier until certain conditions were met.. On Tue, Dec 3, 2013 at 8:52 PM, Allen Wirfs-Brock <al...@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 > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
