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?
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
