Protocol library as alternative to refinements (Russell Leggett)

Benjamin (Inglor) Gruenbaum inglor at gmail.com
Tue Oct 22 08:26:49 PDT 2013


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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131022/e96212b4/attachment.html>


More information about the es-discuss mailing list