• Russ Lewis (42/42) Mar 18 2004 In the discussion above about multiple inheritance, I pointed out how it...
• Matthew (10/52) Mar 19 2004 This could be the nexus of the mixins solution. How about

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

In the discussion above about multiple inheritance, I pointed out how it 
can be useful to have an interface which mirrors a given class, so that 
you can do MI by hand:

class A {...}

interface B_interface {...}
class B,B_interface {...}

/* class C is (sort of) an MI mix of A and B */
class C : A,B_interface {
   B b;
   /* create wrappers for b's fields by hand here */
}

But then the programmer has to do dual maintainence, keeping B_interface 
synchronized with B.  Plus, the code is harder to read, since you have 
variables of type B_interface (rather than B) floating around.

By why not have the compiler automatically generate a type "interface 
B", which is an interface which has the same implementation as B?

class A {...}
class B {...}	/* no explicit interface */

class C : A,interface B {
   B b;
   /* same wrappers */
}

Of course, if this was legal, then this would also be a conceivable 
implementation for C:

class C : B,interface A {
   A a;
   /* wrappers for A */
}



Of course, now you have to ask what this variable represents:
	A a;
Is it a reference to A, or a reference to interface A?  If the former, 
then you could use the data members of A; if the latter, then you could 
use only the methods.

I would suggest that
	A a;
should be a reference to interface A, and that
	class A a;
should be a reference to A.  I think that this is a good idea because it 
allows maximum portability (the variable a can be assigned references to 
a wider range of types).  Users who need a slight performance boost or 
who want to access data directly (not through properties) can use the 
slightly more verbose syntax.

"Matthew" <matthew stlsoft.org> writes:

This could be the nexus of the mixins solution. How about

class C
    :    A
    ,    mixin B
{
    mixin B b;
}

?

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:c3dqud$31do$1 digitaldaemon.com...
 In the discussion above about multiple inheritance, I pointed out how it
 can be useful to have an interface which mirrors a given class, so that
 you can do MI by hand:

 class A {...}

 interface B_interface {...}
 class B,B_interface {...}

 /* class C is (sort of) an MI mix of A and B */
 class C : A,B_interface {
    B b;
    /* create wrappers for b's fields by hand here */
 }

 But then the programmer has to do dual maintainence, keeping B_interface
 synchronized with B.  Plus, the code is harder to read, since you have
 variables of type B_interface (rather than B) floating around.

 By why not have the compiler automatically generate a type "interface
 B", which is an interface which has the same implementation as B?

 class A {...}
 class B {...} /* no explicit interface */

 class C : A,interface B {
    B b;
    /* same wrappers */
 }

 Of course, if this was legal, then this would also be a conceivable
 implementation for C:

 class C : B,interface A {
    A a;
    /* wrappers for A */
 }



 Of course, now you have to ask what this variable represents:
 A a;
 Is it a reference to A, or a reference to interface A?  If the former,
 then you could use the data members of A; if the latter, then you could
 use only the methods.

 I would suggest that
 A a;
 should be a reference to interface A, and that
 class A a;
 should be a reference to A.  I think that this is a good idea because it
 allows maximum portability (the variable a can be assigned references to
 a wider range of types).  Users who need a slight performance boost or
 who want to access data directly (not through properties) can use the
 slightly more verbose syntax.