Protocol library as alternative to refinements (Russell Leggett)

Dean Landolt dean at deanlandolt.com
Tue Oct 22 13:50:41 PDT 2013


On Tue, Oct 22, 2013 at 4:07 PM, Russell Leggett
<russell.leggett at gmail.com>wrote:

> On Tue, Oct 22, 2013 at 2:34 PM, Benjamin (Inglor) Gruenbaum <
> inglor at gmail.com> wrote:
>
>> On Tue, Oct 22, 2013 at 8:10 PM, Russell Leggett <
>> russell.leggett at gmail.com> wrote:
>>
>>> > Revised algorithm:
>> > 1. If receiver has protocol method symbol as a property, use that as
>> override.
>> > 2. Try to use protocol methods - start by checking receiver type
>> mapping, then check up type hierarchy for any matches, and finally if no
>> matches, use the default if defined.
>> > 3. Finally, if no matches and no default, check prototype for method of
>> same name.
>> > Does that sound better?
>>
>> Much :)
>>
>
> Actually, let me revise 3:
> 3. Finally, if no matches and no default, attempt to call a method of the
> same name (not affected by variable name or aliasing) on the receiver.
>
> Something like this:
>
>     const P = new Protocol("foo");
>
>     // naive, non-native implementation of P.methods.foo would be
> something like
>     function foo(...args){
>         if(P.symbols.foo in this){
>             //P.symbols holds a symbol for each method
>             return this[P.symbol.foo](...args);
>
>         }else if(P.contains(Object.getPrototypeOf(this))){
>             //contains and lookup might be backed by a weakmap or
> something,
>             //but it would also need to go up the type chain
>             let myFoo = P.lookup(Object.getPrototypeOf(this)).foo;
>             return this::myFoo(...args);
>
>         }else if(P.getDefaults().hasOwnProperty("foo")){
>             let defaultFoo = P.getDefaults().foo;
>             return this::defaultFoo(...args);
>
>         }else{
>             this.foo(...args);
>         }
>     }
>
> If this seems acceptable, I'll update the gist.
>

This seems sensible, though it's a bit more flexibility than I'd prefer.
What's not completely clear to me is whether this dispatching is defined by
the protocol method implementation or whether it's something that's
standardized? If the latter, I'd be concerned by all this flexibility. If
it's the former (and you can just grab a dispatch implementation from some
module) I guess it doesn't matter.

So *if *the implementation controls the dispatching, the point I was trying
to make about the "default" method not really being default is just that it
could just as well be inlined. Sure, it'd be nicer if it was defined
separately so they can be extracted and used independently, but assuming
custom dispatch then defaults are really up to your dispatch algorithm,
right? Do I have this about right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131022/986818ad/attachment.html>


More information about the es-discuss mailing list