Protocol library as alternative to refinements (Russell Leggett)

Russell Leggett russell.leggett at gmail.com
Mon Oct 21 23:13:53 PDT 2013


>
>
> > I can see most of your examples involve the interaction between the
> protocol method and a method supplied on the object itself... They
> definitely complicate things... I guess I would say that I would have this
> throw an error. ... Skipping foo on the object because its not a function
> seems too magical.
>
> Skipping `foo` on the object because it is not a function is too magical
> in my opinion too. Working out how instance methods work in this scenario
> seems like quite the task to me. The step of putting the protocol _between_
> the object and the prototype sounds pretty hard to get right in particular.
> 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.


>
>

> >> ---- Case 3:
> > Ah, yes, I had thought about this a bit, but it had never made it into
> my gist at all. Let me revise my algorithm:
> > 4. true - use Bar.foo
>
> This makes some sense. About scope resolution more generally I just want
> to make a note that in C# extension methods, the extension method is always
> the _last_ candidate. It would check anywhere in the inheritance chain
> _before_ attempting to evaluate the extension method. For example:
>
>    ```
>     public class Bar
>     {
>         public int GetFive() { return 5;}
>     }
>     public class Foo : Bar{}
>
>     public static class FooExt
>     {
>         static int GetFive(this Foo bar)
>         {
>             return 5555;
>         }
>         static string ToString(this Foo bar)
>         {
>             return "Hi";
>         }
>     }
>      static void Main(string[] args)
>         {
>             Console.WriteLine((new Foo()).GetFive()); // this prints 5
>             Console.WriteLine(new Foo())); // Uses the implementation of
> Object.ToString .
>         }
>     ```
>
> This is a major difference between this proposal and C# extension methods.
> However, I'm not sure it's bad. Would you mind making an argumnt for
> prioritizing the protocol method over an object method?
>

Well I would start by pointing out that the two really are different
mechanisms with different strengths and weaknesses. Protocols are more than
a means of extension - they are also polymorphic and can really take
advantage of the equivalent of interfaces across data types in addition to
their extension. In a way, they are more similar to Haskell typeclasses
than extension methods. There is also the obvious difference that protocols
can be efficiently implemented in a dynamic language where extension
methods cannot :)

So anyway, the reason why prioritizing protocols is because there is
potential value in the protocol itself. The protocol *is* an interface - a
contract which can be polymorphic over different types. The same way that
two protocols can have methods with the same name but different semantics,
it would make sense that a protocol could be defined, and need to be
applied to a type that already has the method. There is value for the
protocol version to override the type's built in version. Because there is
no ambiguity in the intent of using the protocol instead of the prototype,
I think protocol should win. C# uses uniform syntax so the intent cannot be
known if the extension method was intended vs the type's method. Even
interfaces in the Java/C# worlds can't handle that type of clashing. If two
interfaces have methods with the same name and signature, you can only have
a single implementation. In those languages it is rarely a problem because
of the ability for overloading, but with JavaScript its just one name, one
method.

I'm not opposed to simplifying the algorithm, and perhaps protocol methods
should always take a backseat similar to C#, but that just doesn't seem
right to me. If I create a protocol with a map method and I define it for
Array, I would expect that to take priority, no? You're directly calling
arr::map not arr.map - maybe its a ParallelCollection protocol and you want
to override map to be parallel with web workers or something.

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


More information about the es-discuss mailing list