Protocol library as alternative to refinements (Russell Leggett)

Russell Leggett russell.leggett at gmail.com
Wed Oct 23 08:23:41 PDT 2013


On Tue, Oct 22, 2013 at 4:50 PM, Dean Landolt <dean at deanlandolt.com> wrote:

>
>
>
> 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?
>

I'm afraid that I'm a little lost by your confusion, so I'll just do the
best I can to answer your questions. First, the foo function I wrote out
was simply a bit of code to specify the algorithm I was thinking of in more
concrete terms. And again, its pretty naive - I was shooting for simpler
semantics rather than most efficient. So, to try and clarify a little
further:

    const P = new Protocol("foo");

I picture the protocol constructor taking a variable number of string
arguments, or possibly an object similar to Object.create - I went with
strings for now because I couldn't think of what else you would need other
than names. The resulting object would be an instance of Protocol. For each
string argument you provided the constructor, the protocol would generate a
special protocol method, and also an associated symbol. When you are
calling the foo method in this case, it has to call an actual method first
(unless there's native support) and that method has to do the dispatch to
your supplied protocol method, the default method, or attempt to call the
method on the instance. I was expecting the protocol library to completely
handle this dispatch, so that foo function I created above would basically
be internal to the protocol, not something written by the user of the
library. Not sure if that clears anything up.

To answer your question more directly, the dispatching would be internal to
protocols. If protocols were done as a library, it would be dictated by the
library author, if it was native, then it would follow a spec and be
implemented by the browser.

- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131023/f284106e/attachment.html>


More information about the es-discuss mailing list