Open Methods: From C++ to D

[Jean-Louis Leroy via Digitalmars-d-announce]

On Thursday, 31 August 2017 at 14:52:43 UTC, jmh530 wrote:
> On Wednesday, 30 August 2017 at 15:59:32 UTC, Jean-Louis Leroy 
> wrote:
>>
>> What happens here is that kick(Animal) is shadowed by 
>> kick(Dog). kick(Animal) is a method but it appears to the user 
>> and the compiler as an ordinary function - which is generally 
>> good. As such it is eligible for UFCS. I would not recommend 
>> this sort of coding, but it's everyone's choice, methods or 
>> not.
>>
>> Likewise, methods can be overloaded (like here 
>> https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12).
>>
>> A current limitation is that default arguments are not 
>> supported (yet), although I think it's just a matter of 
>> putting the effort in.
>>
>> UFCS interacts nicely with methods because you can say 
>> a.plus(b) even if 'plus' is an open method.
>
> I had a chance to try out what I had suggested above and it 
> behaves exactly as I would have expected (i.e. it prints the 
> line "lassie.kick(): ctbark").
>
> You seemed to emphasize UFCS in your response, but that really 
> wasn't what I was intending to focus on. I just as easily could 
> have re-written Dog as below and compiled the program and it 
> would have printed the same thing. Similarly, any Dog or 
> Pitbull type that call kick would return "ctbark", just Animals 
> would return the original results.
>
> class Dog : Animal
> {
>     final string kick()
>     {
>         return "ctbark";
>     }
> }
>
> My point is one can easily mix your openmethods's dynamic 
> dispatch and D's static dispatch. That seems like a great thing 
> that you could emphasize. Simply stated: if you use 
> openmethods, you're not forced to only use openmethods. If you 
> know the type at compile-time, then you can use it. It's only 
> if you want to dynamically dispatch it that you would need 
> openmethods.

Indeed I misunderstood.

Well, I am very pleased that my stuff interacts well with the 
rest of the language - I strive for that. However, I found that 
it is difficult to get people to open their mind to the idea of 
open methods, initially. Unless they come from Lisp, polymorphism 
and membership are almost indissociable for them. I often have to 
jump three hurdles.

1/ They're multi-methods, and I never actually had a use for 
that. That is why I insist so much on openness in the article, 
and throw multiple dispatch in as a bonus only half way through. 
That's also why I call them "open methods" and not 
"multi-methods" or "open multi-methods".

2/ It's just function overloading. Hmmm, polymorphism? But once I 
get past that, it's actually a good thing. People know (more or 
less) how overload resolution (or partial template specialization 
for the more expert) works. So I don't need to explain the rules 
governing dispatch and ambiguities in an abstract way. Usually I 
just say "you already know which override will be picked - it's 
the same as with compile-time overload resolution".

3/ This one is specific to D - UFCS gives me the same thing. 
Hmmm, polymorphism again? But you see why I am very careful with 
anything that may obscure or confuse the message.

I find the interaction of open methods and UFCS particularly cool 
when implementing the "call chain" idiom (e.g. 
a.plus(b).times(c).invert()).