On 24/09/2009 16:30, Andrei Alexandrescu wrote:
Walter and I discussed last night about contravariance and all and could
not find a compelling argument in favor of implementing contravariant
arguments right now. The feature is nontrivial to implement, potentially
surprising, and has a number of odd corner cases.
One feature that does get requested often in C++ and Java is the ability
to choose which class/interface contains the method you want to
override. Consider:
interface Lottery { void draw(); }
interface Figure { void draw(); }
class LotterySimulation : Lottery, Figure {
override void draw();
}
Right now draw() overrides both methods, but you'd want to override them
separately. You could do so through an intermediate interface:
class Figure2 : Figure { void draw2() { return draw(); } }
class LotterySimulation : Lottery, Figure2 {
override void draw();
override void draw2();
}
There are a few problems with this, among which the fact that
LotterySimulation now cannot inherit another class; the one class slot
was occupied by Figure2.
So I was thinking of this:
class LotterySimulation : Lottery, Figure {
override(Lottery) void draw();
override(Figure) void draw();
}
This is easy to implement, scales well, and has good real world uses.
What say you?
Andrei
in your code you tried to rename draw(), why not make this explicit?
provide syntax to disambiguate by explicitly renaming the functions.
for example:
class A : Figure, Lottery {
override(Figure.draw) void draw() { .. }
override(Lottery.draw) void draw2() { .. }
}
please give more consideration to the idea than to my initial suggested
syntax.
btw, this is how Eiffel implements MI, the programmer specifies the
mapping between names from the base class(es) and the subclass in order
to solve ambiguities.
