Open Methods: From C++ to D

[jmh530 via Digitalmars-d-announce]

On Wednesday, 30 August 2017 at 15:10:03 UTC, Jean-Louis Leroy 
wrote:
>
> I sort of agree, and somewhat regret not picking 'openmethod'. 
> I considered both. Also @specialize. If anyone had pushed for 
> @openmethod before the article, I would almost certainly have 
> given in.
>
> My reasoning was, I hope to promote the term 'method' as the 
> standard name for polymorphism from outside, as opposed to 
> vfunc. We usually say "virtual functions", rarely "virtual 
> member functions". Membership is implicit.

We had some discussion about what to name it in the original 
announce thread, but I didn't want to get too focused on 
bikeshedding the names and you had made good points. @method is 
probably better than @specialize. Not sure what additional 
information you get from @openmethod, given that you're already 
importing from openmethods, but I don't really care that much.

One thing you didn't really cover is how seamlessly interacts 
with normal polymorphism. For instance, what if to your first 
example, I add the following function (note: without @method) and 
adjust main as below. I see no reason why this shouldn't work. 
But you wouldn't be able to create a string kick(Animal animal) 
function since that is created by the mixin.

string kick(Dog dog) { return "ct bark"; }

void main()
{
   updateMethods();
   import std.stdio : writeln;
   Animal snoopy = new Dog, hector = new Pitbull;
   writeln("snoopy.kick(): ", snoopy.kick()); // bark
   writeln("hector.kick(): ", hector.kick()); // bark an dbite
   Dog lassie = new Dog;
   writeln("lassie.kick(): ", lassie.kick()); // ct bark
}