On Tue, Oct 22, 2013 at 11:26 AM, Benjamin (Inglor) Gruenbaum < [email protected]> wrote:
> > > Russell, thanks for the reply, it clarified a lot. I just wanted to > mention that I did not bring up C# extension methods to suggest this > behavior for protocols but just to illustrate how a different system for > addressing a similar problem (in a different environment) does it. I do not > think Protocols should behave this way :) > > On Tue, Oct 22, 2013 at 9:13 AM, Russell Leggett < > [email protected]> wrote: > >> I don't like thinking of reading from the prototype (as in the case > of fetching a method) any differently from reading from the own object. > After all sharing functionality is at the very core of prototypical > inheritance. > >Yeah, I'm not exactly married to it, but I liked the idea of being able > to override at the instance level, therefore giving own properties highest > priority. > > I think there is a very specific problem Protocols attempt to solve. I > think that problem is sharing and adding functionality to a type in a > scoped manner. Our other mechanisms for sharing functionality, prototypical > inheritance and mixins do not scope well. What protocols give us is the > ability to share functionality without having to modify the object. I think > the syntax is also really nice and clever. (so far I'm not saying anything > new) > > The way method resolution on the object itself works right now in > protocols sounds pretty complicated though. What if we make it a part of > the protocol instead? What if protocols had a way to define preferring the > object implementation? Don't we already have that in Protocols? > > MyProtocol.extend(Array, {map:Array.prototype.map}); // sorry if that's > incorrect syntax > > Doesn't this let me define that when encountering an array I prefer its > own implementation over the protocol's? What does it really cost us to drop > checking the object and its prototype rather than using the protocol method > always? > > If anything, I'd use the object own properties and prototype chain as a > last fallback after protocol options have been exhausted. I don't really > see an obvious use case where I want to polymorphically prefer the object > implementations over the protocols and if I do, I can just use > Protocol.extend to specify that in that case. > > The only other thing that bothers me in the spec is that you specify by > classes which sounds a bit problematic to me (I don't see an obvious > behavioral way though (how do I say "Array like"?), and having a default > implementation kind of addresses that). > > On Tue, Oct 22, 2013 at 5:35 PM, Dean Landolt <[email protected]> > wrote: > >> > I think the idea of overriding at the instance level is appealing too, > but doesn't dispatching on a string key open the door to the kinds of > naming conflicts the concept so elegantly solves otherwise? > > I agree that arr.map is questionable for protocol walking, but it's just > as questionable on the instance because of possible name conflicts! > > What naming conflicts do you see here? > > Say you have an object for which you want to implement the Cowboy and Canvas protocols (to borrow /be's favorite example). Both implement a "draw" method, but when you try to import from both protocols you'll naturally have to rename one or both. Now say you want to override Cowboy's `draw` method on an instance? You'll end up clobbering the Canvas protocol's draw method with the obviously wrong function. Not cool. This can be easily corrected with Symbols.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
