Protocol library as alternative to refinements (Russell Leggett)

Dean Landolt dean at
Tue Oct 22 09:12:58 PDT 2013

On Tue, Oct 22, 2013 at 11:26 AM, Benjamin (Inglor) Gruenbaum <
inglor at> 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 <
> russell.leggett at> 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, {}); // 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 <dean at>
>  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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list