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
}
