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

Reply via email to