Since the class syntax is purely declarative it leaves people who need to do abstractions of classes behind. Imagine something like Backbone or Ember.
http://backbonejs.org/#Model http://emberjs.com/guides/models/ If they want to use super their class abstractions need to be updated to use toMethod internally. On Tue, Dec 3, 2013 at 4:48 PM, Andrea Giammarchi < [email protected]> wrote: > 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 > > -- erik
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
