Protocol library as alternative to refinements (Russell Leggett)

Dean Landolt dean at deanlandolt.com
Tue Oct 22 09:44:09 PDT 2013


On Tue, Oct 22, 2013 at 12:19 PM, Benjamin (Inglor) Gruenbaum <
inglor at gmail.com> wrote:

> Dean Landolt <dean at deanlandolt.com> 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.
>
> I'm not sure I understand the example. What does a Cowboy's draw method
> do? Is it a specification of the Canvas protocol draw ?
>

They are two entirely different protocols.


> (In that case `.extend`ing the protocol seems to solve it). If you have a
> more concrete use case that would really help.
>

Picture any two protocols that share a method name. Think of another
protocol with a "map" method that means something entirely different from
Collections.methods.map. The specifics aren't important -- just the idea
that these are two independent protocols. You don't want to override a
method of one and accidentally override the other.


> I don't see how this is any different from other variables and general
> naming conflict issues when destructuring.
>
>
The difference is that protocols purport to solve this confusion problem --
it's one of their primary motivations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131022/7cb82965/attachment.html>


More information about the es-discuss mailing list