What if they never needed to do that since everything was workign already as meant?
On Tue, Dec 3, 2013 at 3:24 PM, Erik Arvidsson <[email protected]>wrote: > 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
