Open Methods: From C++ to D

[jmh530 via Digitalmars-d-announce]

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.