Protocol library as alternative to refinements (Russell Leggett)

Dean Landolt dean at
Tue Oct 22 09:53:48 PDT 2013

On Tue, Oct 22, 2013 at 12:44 PM, Russell Leggett <russell.leggett at
> wrote:

> 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.
> Yes, I'm liking this idea. Protocol always first - override through a
> symbol. Honestly, the more I think about it, the more I think overriding
> won't happen much and therefore isn't a huge problem, making it more
> specific through a symbol is not a bad idea.
> Last question - what about the priority of the defaults? Are they still
> prioritized over prototype? I was worried at first about unintentional
> clobbering the other way, but then realized that its easy to check for the
> method in the default if you want to prioritize the prototype over the
> default.
>     Cowboy.defaults({
>         draw(){
>             if(typeof this.draw === "function"){
>                 this.draw();
>             }else{
>                 //something here
>             }
>         }
>     });

This is an interesting point -- the implementation could choose whether or
not to dispatch to an instance, and how. At this point I wouldn't call them
"defaults" since they'd always be run, and would be responsible for their
own dispatching. I still think dispatching on strings would defeat one of
the biggest advantages of protocols, but this approach is flexible enough
to allow that. Also, it doesn't try to intercede between own and prototype
lookup, which is much nicer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list