Differing implementations for a function in two interfaces

[BCS]

In article <e1s99b$sop$1 at digitaldaemon.com>, Hasan Aljudy says...
>
>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.

say that the interfaces are part of closed source libs, as such the only part
that is available for redesign is that part that is being designed by the
hypothetical subordinate. 

>
> > 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; 

This is exactly what I am saying should be done

> namely, function names are not simply identifiers any more.

Not necessarily a syntax like the following wouldn't require any change to the
function definition syntax. Also it would allow a function to implement an
interface without having the same name as the function in the interface (useful
if that name is already used by a inherited class).

class C : I, J
{
int getI(){...}
int getI(){...}

alias getI I.get;
alias getJ J.get;
}
>
>2. I don't see where's the performance gain; you're still using vtables.

Yes but only one vtable and only one level of function call. Alternate solutions
require the use of otherwise unneeded object with methods that simply wrap other
methods. I would consider that pure waste.

>
>I don't even see how it's supposed to be a "better design".
>
I am considering this problem from the standpoint of the efficiency of the final
product. I consider this objective to be of great importance, more so than the
how easy it is to write the program (and to some degree the simplicity of the
language). From this perspective, all available solutions to the problem are
wistful. Some people take the opposite view, which supports different solutions.