Steven Schveighoffer wrote:
On Thu, 24 Sep 2009 09:30:46 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> 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?
In fact, your example *still* does not work, since draw2 calls draw :)
I think you meant:
class Figure2 : Figure { abstract void draw2(); void draw() { return
draw2();} }
And I think actually, this still wouldn't work because LotterySimulation
is overriding draw from Figure2. Maybe if you make it final in Figure2?
You're right. I haven't managed to do it yet (the one-leg renaming works
in C++, though I forgot the details). All the more argument for defining
the feature.
Andrei