Multiple inheritance in Java/C#

[Hung Jung Lu]

Hi,

I think Microsoft did look into Python when they designed C#. (E.g.
they got rid of checked exceptions of Java.) However, they followed
Java in avoiding multiple inheritance (MI), which is a great leap
backward from C++, in my opinion. I understand the why of avoiding
virtual data members, since performance is an issue. I understand the
problems of MI in C++. But the cure (using interfaces) seems worse
than the disease itself. Now if you change an interface, you have to
go and change all classes that use the interface. For Java, this is
discussed in:

http://www.cyberdyne-object-sys.com/oofaq2/DynInh.htm

Standard reply is a cold sholder: "interfaces are not meant to be
changed". But we live in the real world. Also, I don't think it is fun
to write zillions of getters/setters, and wrappers for implementing
interface methods in MI of interfaces. Sure, you can have the IDE
writing some of these codes, but that brings other sets of problems,
too.

Python of course is free from these problems. To start with, Python
data members are virtual, easily overridable. I remember people used
to complain that Python does not support encapsulation and that
private data in inheritance chain could be overriden. But that
actually is GOOD in many cases, and especially in MI a la MixIn.

Does anyone know how to emulate Python-like MI in Java/C#?

regards,

Hung Jung

[Thomas]

On Tue, 18 Nov 2003 20:31:35 -0800, Hung Jung Lu wrote:

I think Microsoft did look into Python when they designed C#.
I had the same feeling.

However, they followed Java in avoiding multiple inheritance (MI),
which is a great leap backward from C++, in my opinion.
There are pros and cons for MI; I never liked the MI design (e.g.
because it can lead to nasty bugs, which are really hard to find)
and prefer C#'s way.

But the cure (using interfaces) seems worse than the disease
itself. Now if you change an interface, you have to go and
change all classes that use the interface.

Standard reply is a cold sholder: "interfaces are not meant
to be changed". But we live in the real world.

At least, the compiler tells you exactly what to do; in my
experience, this leads to very stable applications, even if the
application gets very large. (If you work with MI, it might happen
as well that you have to change many classes when you make changes
to the base classes.)

I hope that C# uses it's chance of being a (IMHO) well designed
language, which can concentrate now on performance and stability
issues (and not on implementing new features). Python used to be
that way, but in the last time, it is developing too fast (IMHO).

--
mailto: pu******@hotpop.foo (where: foo = com)

[Sean Ross]

"Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e**************************@posting.google.c om...

Does anyone know how to emulate Python-like MI in Java/C#?

Hi.
I believe this is usually done using a design pattern - I think its called
"the proxy object pattern" or it may be "the delegator pattern", I'm not
sure. I know that for doing CORBA programming with Java, you can have tie
classes (which I believe use the aforementioned design pattern) generated to
help simulate multiple inheritance. The idea is something like this: you
have class C which inherits from A but you would like to have a class that
inherits from A and B; make a class D that inherits from B, and that keeps
an instance of C; D is your class that "inherits" from A and B; when you
have an instance of d and you call a method derived from A, you delegate to
the instance of C, otherwise you handle it directly. I think that's the
general idea. You should be able to find specific examples somewhere online.

HTH
Sean

[Michele Simionato]

hu********@yahoo.com (Hung Jung Lu) wrote in message news:<8e**************************@posting.google. com>...

Hi,

I think Microsoft did look into Python when they designed C#. (E.g.
they got rid of checked exceptions of Java.) However, they followed
Java in avoiding multiple inheritance (MI), which is a great leap
backward from C++, in my opinion. I understand the why of avoiding
virtual data members, since performance is an issue. I understand the
problems of MI in C++. But the cure (using interfaces) seems worse
than the disease itself. Now if you change an interface, you have to
go and change all classes that use the interface. For Java, this is
discussed in:

http://www.cyberdyne-object-sys.com/oofaq2/DynInh.htm

Standard reply is a cold sholder: "interfaces are not meant to be
changed". But we live in the real world. Also, I don't think it is fun
to write zillions of getters/setters, and wrappers for implementing
interface methods in MI of interfaces. Sure, you can have the IDE
writing some of these codes, but that brings other sets of problems,
too.

Python of course is free from these problems. To start with, Python
data members are virtual, easily overridable. I remember people used
to complain that Python does not support encapsulation and that
private data in inheritance chain could be overriden. But that
actually is GOOD in many cases, and especially in MI a la MixIn.

Does anyone know how to emulate Python-like MI in Java/C#?

regards,

Hung Jung

Yeah, I am not convinced at all by the interfaces strategy; if not
real multiple inheritance, they could at least have provided something
along the way of Ruby's mixins.

About implementing Python MI in Java/C#: in principle you could do it
yourself, by following the MRO algorithm described in

http://www.python.org/2.3/mro.html

In practice, I do expect to implement MI properly to be cumbersome
and with a (possibly high) performance price.

A good idea is to ask Jython developers.
Michele Simionato

[Hung Jung Lu]

"Sean Ross" <sr***@connectmail.carleton.ca> wrote in message news:<4W*********************@news20.bellglobal.co m>...

Hi.
I believe this is usually done using a design pattern - I think its called
"the proxy object pattern" or it may be "the delegator pattern", I'm not
sure. I know that for doing CORBA programming with Java, you can have tie
classes (which I believe use the aforementioned design pattern) generated to
help simulate multiple inheritance. The idea is something like this: you
have class C which inherits from A but you would like to have a class that
inherits from A and B; make a class D that inherits from B, and that keeps
an instance of C; D is your class that "inherits" from A and B; when you
have an instance of d and you call a method derived from A, you delegate to
the instance of C, otherwise you handle it directly. I think that's the
general idea. You should be able to find specific examples somewhere online.

Thanks. I am finding it to be the standard approach. In short:

(containment+delegation) ---> aggregation.

Kind of laborious. But that's the way of life without true MI.

Hung Jung

[Hung Jung Lu]

Thomas <pu******@hotpop.foo> wrote in message news:<pa****************************@hotpop.foo>.. .

There are pros and cons for MI; I never liked the MI design (e.g.
because it can lead to nasty bugs, which are really hard to find)
and prefer C#'s way.
If you use MI to inherit classes and do cascade calls (calling parent
methods with same name, like the case of constructors) up the tree of
inheritance, sure, you get into big mess. But if you use MI as MixIns
without cascade calls, you won't have those nasty bugs. I don't think
I like C# or Java for their lack of MI. You see pairs of
interfaces/implementations all over places, and use
containment+delegation to emulate MI. Things that can be done in a few
lines of code in C++, will be typically multiplied by a factor about 3
when you do them in Java/C#. More over, if you change your interface,
say, just adding one more method, you'll have to make changes all over
places.
At least, the compiler tells you exactly what to do; in my
experience, this leads to very stable applications, even if the
application gets very large. (If you work with MI, it might happen
as well that you have to change many classes when you make changes
to the base classes.)
I think we have different purposes for MI. I use MI for MixIns, not as
real classes, and no cascade calls upstream. The value of MixIns to me
is in their code/action, not in their object/data. I can understand
difficulties when you use MI for object/data. In C++ I can add a new
method in a great-grand-parent class in line, and touch the code only
in two spots: where it is defined, and where it is used. In Java/C#,
it would be hell.
I hope that C# uses it's chance of being a (IMHO) well designed
language, which can concentrate now on performance and stability
issues (and not on implementing new features). Python used to be
that way, but in the last time, it is developing too fast (IMHO).

I can't speak on how well designed it is. But I do know that both Java
and C# are now adding generic templates. So at least the original
designs were not complete.

Hung Jung

[Oren Tirosh]

On Tue, Nov 18, 2003 at 08:31:35PM -0800, Hung Jung Lu wrote:

Hi,

I think Microsoft did look into Python when they designed C#.

In C# 2.0 it looks like they copied Python's generator functions:

http://dev.r.tucows.com/extdocs/c_sh...l#_Toc48187963
Oren

[Duncan Booth]

Oren Tirosh <or*******@hishome.net> wrote in
news:ma************************************@python .org:

On Tue, Nov 18, 2003 at 08:31:35PM -0800, Hung Jung Lu wrote:

Hi,

I think Microsoft did look into Python when they designed C#.
In C# 2.0 it looks like they copied Python's generator functions:

http://dev.r.tucows.com/extdocs/c_sh...l#_Toc48187963

That looks fun. I see they've also picked up on lambda functions and nested
scope variables. I especially liked this:
static void Main() {
foreach (D d in F()) d();
} .... static D[] F() {
D[] result = new D[3];
int x = 0;
for (int i = 0; i < 3; i++) {
int y = 0;
result[i] = delegate { Console.WriteLine("{0} {1}", ++x, ++y); };
}
return result;
}

the three delegates capture the same instance of x but separate
instances of y, and the output is:

1 1
2 1
3 1

--
Duncan Booth du****@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?