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.

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