Protocol library as alternative to refinements (Russell Leggett)

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


On Tue, Oct 22, 2013 at 11:26 AM, Benjamin (Inglor) Gruenbaum <
inglor at gmail.com> 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 gmail.com> 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 <dean at deanlandolt.com>
>  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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131022/16c60941/attachment.html>


More information about the es-discuss mailing list