Differing implementations for a function in two interfaces

[Hasan Aljudy]

BCS wrote:
> In article <e1s2sr$n4s$1 at digitaldaemon.com>, Hasan Aljudy says...
> 
>>What you want is exactly what polymorphism is designed for. I really 
>>don't understand what's your problem.
>>
> 
> I don't believe that D can solve the following problem. I can see several way to
> get a _similar_ effect but all have substantial penalties involving code
> complexity, speed or maintainability/extensibility
> 
> If you can use you suggested approach to solve this problem I would be pleased
> to see it.
> ---------------
> You are given this (you may not modify it)
> 
> interface I {int get();}
> interface J {int get();}
> 
> 1) You need to make a class C that implements both I and J that has different
> action for I.get and J.get.
> 
> 2) Classes derived from C must be able to override the action of both I.get and
> Jget
> 
> 3) Given an instance, c, of the class C, the following statements must work.
> I i = c;
> i.get	// must call the appropriate I.get even if c is of a derived type.
> J j = c
> j.get	// must call the appropriate J.get even if c is of a derived type.
> 
> 4) Converting a C object to an I or J interface must not rely on the overloading
> of the cast operation (e.i. "I i = c;" must not call any methods)
> 
> 5) Must be simply extendable to interfaces with lots of function (one more
> function in I must not require more than one function be defined to keep C up to
> date)
> 
> I believe these requirements for a programming solution to be vary reasonable.
> If I were working in a programming shop and assigned a subordinate to the
> problem as defined through point 2, I would expect that 3-5 would be assumed.

I would dump these requirements, talk to the guy who set them, and try 
to figure out what problem he was trying to solve, then I'd make a 
better design.

 > The problem I stated before is conceptually vary easy to solve: somehow,
 > explicitly set the contents of the vtbls used by C when cast to I or 
J. The
 > solution that you proposed, while workable, is a vary poor design. It is
 > wasteful in runtime, program size, memory usage, code size and 
maintenance cost.

It's not very easy, and I don't see how it improves performance.

1. It requires a substantial change to the grammar; namely, function 
names are not simply identifiers any more.

2. I don't see where's the performance gain; you're still using vtables.

I don't even see how it's supposed to be a "better design".