dotnet clr: Hi all,

I wanted to know the reason Why in .NET multiple inheritance is not
supported?

Thanks,

[quoted text, click to view]

It's a design nightmare.

By the way, you CAN emulate it. Create a wrapper class containing

A cool design about inheritance is that allows access to protected methods,
properties and fields and not allows the access to any class that is not
derived from it.

Multi inheritance can be a design nightmare, but it can't be emulated.

Creating a wrapper containing instances of the classes you want to inherit
won't let you access to protected methods, properties and fields. The only
thing it will do is a super class with public methods and properties from
the instances inside it. Also this is messy because you have to create a
wrapper for each method you want to expose from each instance inside the
super class, for example if you want to expose the methods of 2 classes
where each one has 20 methods, then you need to create 40 wrappers methods.

I didn't understand what you mean with design nightmare.

Is it a nightmare for the designer of the language or is it a nightmare for
the programmer using it?

I think muti-inheritance should be used when really is necessary, and there
cases where it is pretty useful and "emulate" it is almost impossible.

For example:

I needed inherit each Windows control to enhance it with some functionality.
This extra code is complex and requires use properties and methods from the
base control.
If I create an extra class to make the enhancement then I need create
methods accepting a lot of parameters creating a crappy design, also inside
the wrapper class don't let me access to the methods from the base control;
a solution is sending a instance of the derived control to the wrapper
class, but inside the wrapper class doesn't let you access to protected
methods from the base control.
To fix that is nescesary create a wrapper "public method" from the protected
method and send the control instance to the wrapper class, but then these
methods will be accessed for any class.
They could be declared as "internal methods", but it doesn't solve the
problem because now those methods are exposed to the complete assembly.

Finally the only solution was duplicating the code on each control derived
from Windows control.

Where maintain the code is a pain, one change on the enhancement logic
require change every control logic.

Muti-inheritance could have solved the problem really nicely.

Gustavo.

[quoted text, click to view]

You comment made me wondering and I start reading about mixin, and it is
really a great idea.
After read many articles like this:

http://www.rubycentral.com/book/tut_modules.html

I can guess that mixin is created on compilation time mixing the source code
of the "module" with the source code of the class.
Basically duplicating the "module" code (probably "module class" for c-sharp
:) ) on each class to be injected.

This is not the same than multi inherence but could resolve 90% of the
problems out there.

I hope they evaluate it and implement it on CS 2.0 or 3.0.

Gustavo.

[quoted text, click to view]

[quoted text, click to view]

If I understand correctly (both your requirements and the definition of
Mixin), a Mixin would have solved the problem even better. There may be hope
for the future, since I've read somewhere (the net is vast...) that the C#
team is considering Mixin amongst the possible extensions for the future
releases.
Smalltalk aficionados, also limited by single-inheritance, think that Mixins
are a much better solution, in general, to the problems that people try to
solve with multiple-inheritance and they've been playing with them for a
while now.
--
WildHeart'2k5

[quoted text, click to view]

Actually, as far as I understand, since Smalltalk (and Ruby.. ?) is an
interpreted language, Mixins are merged at runtime. I believe that this is a
demo of a simplistic implementation of a Mixin in .NET (for a very nice
language called Boo):
http://docs.codehaus.org/pages/viewpage.action?pageId=13653 The author calls
it Mixup, but the similarities are striking.
Anyway, however they might be implemented in C# (if ever) I am sure they
would make for an interesting addition, as long as the price to pay (I am
thinking of performance) is low! The example in boo is probably relatively
slow because it's based on reflection.
Also check the sample page for another (non .NET) little language called
"Io": http://www.iolanguage.com/about/samplecode/ There's a very simple but
effective implementation of Mixins. It's interesting the author's comment
"Now multiple objects use it so it's an 'aspect'". This probably also means
that all those who advocate for the introduction of AOP (Aspect Oriented
Programming) in C#, are also rowing in this same direction :)
--
WildHeart'2k5