why C# can't support multiple inheritance?

Re: why C# can't support multiple inheritance?

It was a design decision from the docs. It was thought that MI was too
complex and not implemented correctly by most programmers and the
incremental benefit was not large enough to justify it in most cases.
Moreover, containment is considered to be a better choice over inheritance.

--
William Stacey, MVP

"Matthew Louden" <mattloude@hotm ail.com> wrote in message
news:OKYDUwAxDH A.2000@TK2MSFTN GP11.phx.gbl...[color=blue]
> I want to know why C# doesnt support multiple inheritance? But why we can
> inherit multiple interfaces instead? I know this is the rule, but I dont
> understand why. Can anyone give me some concrete examples?
>
>[/color]

why C# can't support multiple inheritance?

Well, if I get too far into this topic, I'll probably end
up demonstrating just how much I DON'T know about C#...
LOL But here goes my best "layman's" explanation:

Computer programming languages, at their lowest levels,
all operate on the same basic principles, and even teh
most complex and intriguing constructs are still
represented by some faily basic data types, coupled with
some pretty slick techniques for maknig it all work. Such
is the case with OOP.

A lot goes on under the covers to make things like
inheritance and virtual fxns to work. For example, when
you have base class a, with virtual fxn f1(), and then
class's b & c each inherit from a, and then override f1()
with their own versions, how does C++ know, when you
create p (a pointer to an "a"), but point it at a "b" or
a "c" (a derrived type of an "a"), how does C++ know that
it's suposed to call b::f1() and not a::f1() if the only
thing that a pointer to an "a" contains is information
about an "a", not about "b"'s "c"'s or any other types?

The answer is that under the covers, it creates something
called a vtable, which I won't get into explaining
(because I'd probably get it wrong anyway). It uses the
vtable, completely invisibly to you, to keep track of the
most-derrived versions of virtual fxns.

Enough about C++....

While may say that C# "doesn't use pointer", in fact it
DOES, but it simply wraps them up in Java-like
references. This, among other features of the language,
affords C# the ability to safely make certain kinds of
assumptions about objects and data types that were
programming landmines in C++.

C++, through multiple inheritance, allows one to
conceptually do some pretty bizarre things which, in C#
would have undefined results. For example, consider a C++
base class a, with derrived classes b and c (that is, b
and c each inherit from a.) Now, consider a fourth class,
d, with multiple parent classes b and c or, to look at it
in a different perspective, d has a b which has an a, but
d also has a c which also has an a.... Hmmm.... One "a",
but two instances of it? Or do they share them? Such are
the problems of mutiple inheritance. The structure and
syntax of C++ is such that the behavior of this type of
class is actually defined within the language. C# trades
off some of that (dare I say useless... or at least
dangerous?) flexibility of C++ for a more practical and
streamlined approach. Yes, you do lose multiple
inheritance but, in reality, there are generally more
concise, and certainly safer ways to accomplish the same
tasks. A muliple-inheritance type of object model does
not particularly fit the more contemporary n-tier data and
process model of modern applications, for which C# was
created and, hence, it was determined to be dispensible.

The concept of an inerface in C# does nto syntactically
nor structurally contribute to the language. Instead,
think of interfaces as more of a "contract" that
says, "Any classes that look like this WILL IMPLEMENT
these functions and properties". In that sense,
interfaces are something akin to the MFC pure virtual base
classes, whose sole existence was simply to provide a
foundation upon which to build other classes. Interfaces
allow you to do pertty much the same thing. By creating
an interface, and then including that interface in
subsequent clases, you contractually commit yuorself to
includign all of the prototyped functions in the
interface, eliminating the possibility of forgetting a
crucial behavior or property.

I apologize if some of my answer is convoluded or nto 100%
technically accurate, but hopefully that at least gives
you a fwe things to think about. When I was first exposed
to C#, as a C++ programmer, I was not impressed. I felt
like someone was really sore that Java was finally proven
to be an inferior language, and this was their attempt to
get even with us (LOL). I have recognized since then,
however that while C++ still remains far and above a
superior language for programming, particularly at the
system level, C# marries the best concepts of OOP,
Windows, and the web, with the structure of C++ to provide
a superior design platform for .NET style tiered
applications. :)

Jim
[color=blue]
>-----Original Message-----
>I want to know why C# doesnt support multiple[/color]
inheritance? But why we can[color=blue]
>inherit multiple interfaces instead? I know this is the[/color]
rule, but I dont[color=blue]
>understand why. Can anyone give me some concrete examples?
>
>
>.
>[/color]

Re: why C# can't support multiple inheritance?

It's not that C# can't support multiple inheritance, it's that the C#
developers (and CLI developers) chose not to support it.
There is a history of overly-complex situations that arrise from MI that
easily lead to issues with ambiguous name resolutions as well as weak
inheritance trees, where the design becomes unmaintainable and/or unusable.

I've always felt there are sometimes great reasons for having MI
(particularly in the visual component classes), but I can't say I've really
suffered any withdrawl from not having it. You can still implement as many
interfaces as you want, which in reality, forces you to think and structure
your internals a lot better since you have to code them explicitly - rather
than getting them for "free" with a simple keyword or somesuch.

-Rob Teixeira [MVP]

"Matthew Louden" <mattloude@hotm ail.com> wrote in message
news:OKYDUwAxDH A.2000@TK2MSFTN GP11.phx.gbl...[color=blue]
> I want to know why C# doesnt support multiple inheritance? But why we can
> inherit multiple interfaces instead? I know this is the rule, but I dont
> understand why. Can anyone give me some concrete examples?
>
>[/color]

Re: why C# can't support multiple inheritance?

"Matthew Louden" <mattloude@hotm ail.com> wrote in message
news:OKYDUwAxDH A.2000@TK2MSFTN GP11.phx.gbl...[color=blue]
> I want to know why C# doesnt support multiple inheritance? But why we can
> inherit multiple interfaces instead? I know this is the rule, but I dont
> understand why. Can anyone give me some concrete examples?[/color]

The big issue was how the CLR support could support MI, given the wide
variance among languages as to what MI really looks like, as well as CLS
issues. Many languages have differing ideas about what MI be - OO academic
languages in particular tend to treat this as a place where experimentation
can occur, and the C++ view of MI is just so difficult for average
developers that it's giving the entire idiom a bad name, when the real
problem is the C++ implementation of MI. BTW, advanced developers seem to
find MI useful in C++, see for example the ATL and WTL libraries.

The problem with supporting MI is *not* that MI is inherently complex.
Experience with Eiffel as a teaching language for OOA/OOD and in the field
shows that it is not a complex concept to teach or use, given a reasonable
language implementation. Eiffel has features that take care of issues like
inherited common base classes - in fact, a useful idiom in Eiffel is
repeated inheritance (inheriting the same class multiple times). Get your
head around that one.

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press

Re: why C# can't support multiple inheritance?

>when the real problem is the C++ implementation of MI.
What exactly is wrong with the c++ implementation?

--
Regards,
Alvin Bruney
Got DotNet? Get it here...

"Mickey Williams" <my first name at servergeek.com> wrote in message
news:Ogl0iqDxDH A.2452@tk2msftn gp13.phx.gbl...[color=blue]
> "Matthew Louden" <mattloude@hotm ail.com> wrote in message
> news:OKYDUwAxDH A.2000@TK2MSFTN GP11.phx.gbl...[color=green]
> > I want to know why C# doesnt support multiple inheritance? But why we[/color][/color]
can[color=blue][color=green]
> > inherit multiple interfaces instead? I know this is the rule, but I dont
> > understand why. Can anyone give me some concrete examples?[/color]
>
> The big issue was how the CLR support could support MI, given the wide
> variance among languages as to what MI really looks like, as well as CLS
> issues. Many languages have differing ideas about what MI be - OO academic
> languages in particular tend to treat this as a place where[/color]
experimentation[color=blue]
> can occur, and the C++ view of MI is just so difficult for average
> developers that it's giving the entire idiom a bad name, when the real
> problem is the C++ implementation of MI. BTW, advanced developers seem to
> find MI useful in C++, see for example the ATL and WTL libraries.
>
> The problem with supporting MI is *not* that MI is inherently complex.
> Experience with Eiffel as a teaching language for OOA/OOD and in the field
> shows that it is not a complex concept to teach or use, given a reasonable
> language implementation. Eiffel has features that take care of issues like
> inherited common base classes - in fact, a useful idiom in Eiffel is
> repeated inheritance (inheriting the same class multiple times). Get your
> head around that one.
>
> --
> Mickey Williams
> Author, "Microsoft Visual C# .NET Core Reference", MS Press
> www.servergeek.com
>
>[/color]

Re: why C# can't support multiple inheritance?

Several reasons:

1) .NET is strongly inspired from Java, and Java only supports multiple
inheritance on interfaces (and Java developers seem to be pretty happy with
this restriction).

2) A practical reason: multiple inheritance of classes raises more problems
than multiple inheritance of interfaces. It raises conceptual problems
(repeated inheritance, that Eiffel and C++ address differently) but also
implementation issues (that C++ managed to solve at the expense of strange
hacks, for example pointers being offset when you cast them). Then, my guess
is that the designers of Java (and .NET) weighed the benefits against the
additional complexity (both for the programmer and the implementer of the
language) and decided to forget about multiple inheritance of classes (the
KISS approach).

3) A more fundamental reason: because natural language works the same way,
it favors multiple inheritance of interfaces and single inheritance of
classes. If you analyze classes and interfaces from a linguistic standpoint,
you will quickly reach the conclusion that classes correspond to
substantives (nouns) and that interfaces correspond to adjectives (pure
specifications that do not impose a particular implementation) . This is
obvious if you look at the names of framework level classes and interfaces
(many interfaces have "adjective" names, usually xxx-able forms like
comparable, cloneable, serializable, convertible, etc., and even substantive
names like IList, ICollection are adjectives in disguise: list-like,
collection-like). And, strangely, our grammars let us combine any number of
adjectives with a noun and we naturally define a noun as being another noun
qualified by a set of adjectives (an elephant is a massive gray animal). We
seldom define a noun as being two other nouns (an elephant is an animal and
a ?). So, I have the feeling that this restriction that we impose on our
artificial languages has actually much deeper roots than we think:
naturally, we organize our concepts with single inheritance between nouns
and multiple inheritance of adjectives, we don't use multiple inheritance
between nouns.

Of course, the last point is a bit of a personal theory, but I think that it
provides an interesting justification to the design choices made by Java and
..NET. I got this idea10 years ago, at a time where multiple inheritance was
a hot topic and I was working on a language project (which did not go
through, like 99.99% of these projects). The recent evolution of languages
(Java, C#) conforts me in thinking that this point was valid.

Bruno.


"Matthew Louden" <mattloude@hotm ail.com> a écrit dans le message de
news:OKYDUwAxDH A.2000@TK2MSFTN GP11.phx.gbl...[color=blue]
> I want to know why C# doesnt support multiple inheritance? But why we can
> inherit multiple interfaces instead? I know this is the rule, but I dont
> understand why. Can anyone give me some concrete examples?
>
>[/color]

Re: why C# can't support multiple inheritance?

"Matthew Louden" <mattloude@hotm ail.com> wrote in message news:<OKYDUwAxD HA.2000@TK2MSFT NGP11.phx.gbl>. ..[color=blue]
> I want to know why C# doesnt support multiple inheritance? But why we can
> inherit multiple interfaces instead? I know this is the rule, but I dont
> understand why. Can anyone give me some concrete examples?[/color]

You just opened a can of worms. :)

The root of problems is most statically-typed languages don't support
virtual data fields. Think about it. You have virtual methods, how
come you don't have virtual data fields? (Virtual means overridable by
subclasses.) The answer is performance. With non-overridable, fixed
data fields, the advantage is that you can access the data members by
fixed address offsets, eliminating the needs of vtables (virtual
tables) or other indirect lookup mechanisms (e.g.: name dictionaries
as in dynamically-typed languages), hence getting better performance
and less memory usage.

Not having virtual data fields makes multiple inheritance very hairy.
Suppose C inherits from A and B: (I hope you can see the ASCII diagram
I am drawing)

A B
\ /
C

And suppose both A.x and B.x exist as actual data fields of A and B,
respectively. Suppose C does not have actual data field x. When you
do:

c = new C();
c.x = 1;

Which data field are you going to put the value to? A.x or B.x? You
may say both. But what if later a method in B modifies only B.x? You
get into a mess. You may say, OK, I need to have a single x, at C
level. Well, that's what virtual data field means. But sorry, the
methods in A and B don't handle virtual data fields, they were
pre-wired to use the address offsets of their own data members. So,
the way out in C# and Java is simply to have single class inheritance
and multiple interface inheritance. This way there is no confusion as
which data field to assign the value to.

------------------

Initialization is another problem. The typical example is the
diamond-shaped inheritance:

A
/ \
B C
\ /
D

If you have an object

d = new D()

You run the danger of using the constructor of A twice.

------------------

Does interface-based MI solve the needs of MI? Well, kind of, but it
has some problems.

(a) In interface-based MI, you will find yourself writing a lot of
wrappers to access data. In C# these are the properties, in Java also
known as getters/setters. Why? Because a client that accesses a
particular interface of an object to get c.x cannot really access its
data field directly: the interface is not a real class, hence the
address offset of x inside c is unknown. That's one problem: wrapper
writing, and in Java, pervasive usage of casting.

(b) Another bigger problem is that, in complex cascades of MI, if you
modify (say, add a new method, or change a method's signature) an
interface at the top of the inheritance tree, you will have to go to
the definition of ALL classes that implement the interface, and
implement the new method or do the modifications. You will find
yourselve typing the same code all over places. In order to aliviate
some of these problems, many people resort to "code generators", that
is, pre-compile time applications to help you generate text codes more
easily, so you don't need to type the same code manually all over
places.

(c) If you have actual, existing classes A, B, C, etc. and you want to
use their data and methods in a new class D, you will need to emulate
class MI by using containment and delegation. That is, you store
instances of A, B, C (say, a,b,c) inside your instance of D (say, d),
and then D also implements the respective interfaces of A, B, C, and
delegate d.f() to a.f(). that is:

class MI = containment + delegation

In C# and Java you will find yourself writing a lot of pairs of
interface and actual implementation. And then use
containment+del egation to incorporate existing class features. The
delegation part is painful to write manually. And, again, if you do
some changes at the top of inheritance tree, it could be real pain to
propagate all the changes down the tree. So some people have to resort
to code generators, which does not come with C#: you either have to
build, or to buy. And often you have to be careful not to overwrite
machines generated code on your manually written code.

------------------

C# did improve a lot over Java. Easier property access
(getters/setters). Got rid of checked exceptions (which is a pain in
Java.) But MI remains painful in C#. And this point alone is enough to
limit the future potential of C#. I mean, it's not low-level enough to
replace C++ (from where you can build higher-level languages), and
it's not high-level enough to make writing code easier. The security
features of C# are probably the main reason for its usage. Writing and
maintaining large, modern applications in C# remains painful.

regards,

Hung Jung

Re: why C# can't support multiple inheritance?

I wasn't asking for a comparison between c# and c++. The OP implied that
there was a problem with C++ inheritance. I fail to see that so I was
wondering what lead him to that conclusion.

Liking inheritance to grammar is extremely misleading as well, sleight of
hand. Grammar and syntax is flat. Inheritance forms a nested tree. That
comparison allows you to get away with too much at the expense of
disparaging one kind of implementation. I'll throw it out on a technicality
as well.

Could C++ MI be implemented differently? sure, but hindsight, or the ability
to do it again, it wouldn't be done differently, because given the problem
domain and the context, it works remarkably well. Is there room for
improvement? always, but that's no reason to go bashing C++. MI got a bad
name because C++ is syntactically, and otherwise, difficult to say the
least. MI itself is not a simple concept. Put these two together and it is
not a walk in the park. C# is a *simpler language compared to c# because a
lot has been hidden. That approach has allowed the developers to
re-implement MI in a simpler way - call it interface inheritance or
whatever, the concept is the same. Notice all what had to change to get MI
to be easier on the stomach. It's time to show some respect to the elders.
Without the lessons learned from C++ (c#'s elder), C# would have been headed
for the same hole.

Can of worms for sure.

--
Regards,
Alvin Bruney
Got DotNet? Get it here...

"Bruno Jouhier [MVP]" <bjouhier@clu b-internet.fr> wrote in message
news:uFml2gIxDH A.560@TK2MSFTNG P11.phx.gbl...[color=blue]
> Several reasons:
>
> 1) .NET is strongly inspired from Java, and Java only supports multiple
> inheritance on interfaces (and Java developers seem to be pretty happy[/color]
with[color=blue]
> this restriction).
>
> 2) A practical reason: multiple inheritance of classes raises more[/color]
problems[color=blue]
> than multiple inheritance of interfaces. It raises conceptual problems
> (repeated inheritance, that Eiffel and C++ address differently) but also
> implementation issues (that C++ managed to solve at the expense of strange
> hacks, for example pointers being offset when you cast them). Then, my[/color]
guess[color=blue]
> is that the designers of Java (and .NET) weighed the benefits against the
> additional complexity (both for the programmer and the implementer of the
> language) and decided to forget about multiple inheritance of classes (the
> KISS approach).
>
> 3) A more fundamental reason: because natural language works the same way,
> it favors multiple inheritance of interfaces and single inheritance of
> classes. If you analyze classes and interfaces from a linguistic[/color]
standpoint,[color=blue]
> you will quickly reach the conclusion that classes correspond to
> substantives (nouns) and that interfaces correspond to adjectives (pure
> specifications that do not impose a particular implementation) . This is
> obvious if you look at the names of framework level classes and interfaces
> (many interfaces have "adjective" names, usually xxx-able forms like
> comparable, cloneable, serializable, convertible, etc., and even[/color]
substantive[color=blue]
> names like IList, ICollection are adjectives in disguise: list-like,
> collection-like). And, strangely, our grammars let us combine any number[/color]
of[color=blue]
> adjectives with a noun and we naturally define a noun as being another[/color]
noun[color=blue]
> qualified by a set of adjectives (an elephant is a massive gray animal).[/color]
We[color=blue]
> seldom define a noun as being two other nouns (an elephant is an animal[/color]
and[color=blue]
> a ?). So, I have the feeling that this restriction that we impose on our
> artificial languages has actually much deeper roots than we think:
> naturally, we organize our concepts with single inheritance between nouns
> and multiple inheritance of adjectives, we don't use multiple inheritance
> between nouns.
>
> Of course, the last point is a bit of a personal theory, but I think that[/color]
it[color=blue]
> provides an interesting justification to the design choices made by Java[/color]
and[color=blue]
> .NET. I got this idea10 years ago, at a time where multiple inheritance[/color]
was[color=blue]
> a hot topic and I was working on a language project (which did not go
> through, like 99.99% of these projects). The recent evolution of languages
> (Java, C#) conforts me in thinking that this point was valid.
>
> Bruno.
>
>
> "Matthew Louden" <mattloude@hotm ail.com> a écrit dans le message de
> news:OKYDUwAxDH A.2000@TK2MSFTN GP11.phx.gbl...[color=green]
> > I want to know why C# doesnt support multiple inheritance? But why we[/color][/color]
can[color=blue][color=green]
> > inherit multiple interfaces instead? I know this is the rule, but I dont
> > understand why. Can anyone give me some concrete examples?
> >
> >[/color]
>
>[/color]

Re: why C# can't support multiple inheritance?

"Hung Jung Lu" <hungjunglu@yah oo.com> wrote in message
news:8ef9bea6.0 312170305.1e8d8 a91@posting.goo gle.com...[color=blue]
> "Matthew Louden" <mattloude@hotm ail.com> wrote in message[/color]
news:<OKYDUwAxD HA.2000@TK2MSFT NGP11.phx.gbl>. ..
[color=blue]
> Not having virtual data fields makes multiple inheritance very hairy.
> Suppose C inherits from A and B: (I hope you can see the ASCII diagram
> I am drawing)
>
> A B
> \ /
> C
>
> And suppose both A.x and B.x exist as actual data fields of A and B,
> respectively. Suppose C does not have actual data field x. When you
> do:[/color]

In C++ this is a problem; in Eiffel, it is not a problem. You can just
rename in the inheriting class, so you have C.a_x and C.b_x. Or you can just
rename one of them, and provide an overridden implementation that
multiplexes both. Or you can explicitly select which x you want to use, and
hide the other. Again, this is not an issue with MI in the general case. It
*is* an issue with MI in C++.

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press

Re: why C# can't support multiple inheritance?

"Alvin Bruney" <vapor at steaming post office> wrote in message
news:OXXhdnGxDH A.2396@TK2MSFTN GP09.phx.gbl...[color=blue][color=green]
> >when the real problem is the C++ implementation of MI.[/color]
> What exactly is wrong with the c++ implementation?[/color]

To name three: Too much complexity when base classes occur more than once in
the inheritance tree. Complex pointer semantics when casting an instance of
an MI class to one of the base classes. No easy way to handle name
collisions among base classes.

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press

Re: why C# can't support multiple inheritance?

Why is it an issue?

The solution is to use the scope resolution operator to explicitly specify
your target field. It's a lot cleaner than doing all of this:
[color=blue]
> rename in the inheriting class, so you have C.a_x and C.b_x. Or you can[/color]
just[color=blue]
> rename one of them, and provide an overridden implementation that
> multiplexes both. Or you can explicitly select which x you want to use,[/color]
and[color=blue]
> hide the other.[/color]


--
Regards,
Alvin Bruney
Got DotNet? Get it here...

"Mickey Williams" <my first name at servergeek.com> wrote in message
news:elklw7LxDH A.1484@TK2MSFTN GP09.phx.gbl...[color=blue]
> "Hung Jung Lu" <hungjunglu@yah oo.com> wrote in message
> news:8ef9bea6.0 312170305.1e8d8 a91@posting.goo gle.com...[color=green]
> > "Matthew Louden" <mattloude@hotm ail.com> wrote in message[/color]
> news:<OKYDUwAxD HA.2000@TK2MSFT NGP11.phx.gbl>. ..
>[color=green]
> > Not having virtual data fields makes multiple inheritance very hairy.
> > Suppose C inherits from A and B: (I hope you can see the ASCII diagram
> > I am drawing)
> >
> > A B
> > \ /
> > C
> >
> > And suppose both A.x and B.x exist as actual data fields of A and B,
> > respectively. Suppose C does not have actual data field x. When you
> > do:[/color]
>
> In C++ this is a problem; in Eiffel, it is not a problem. You can just
> rename in the inheriting class, so you have C.a_x and C.b_x. Or you can[/color]
just[color=blue]
> rename one of them, and provide an overridden implementation that
> multiplexes both. Or you can explicitly select which x you want to use,[/color]
and[color=blue]
> hide the other. Again, this is not an issue with MI in the general case.[/color]
It[color=blue]
> *is* an issue with MI in C++.
>
> --
> Mickey Williams
> Author, "Microsoft Visual C# .NET Core Reference", MS Press
> www.servergeek.com
>
>
>[/color]

Re: why C# can't support multiple inheritance?

Hi, my comments are in line:

"Alvin Bruney" <vapor at steaming post office> a écrit dans le message de
news:uqS8lcLxDH A.2452@tk2msftn gp13.phx.gbl...[color=blue]
> I wasn't asking for a comparison between c# and c++. The OP implied that
> there was a problem with C++ inheritance. I fail to see that so I was
> wondering what lead him to that conclusion.[/color]

My post was not a reply to yours, but to the original post. I'm not doing a
comparison between C# and C++, just saying that multiple inheritance between
classes raises more problems (conceptual and technical) than inheritance
between interfaces. Do you question that?
[color=blue]
>
> Liking inheritance to grammar is extremely misleading as well, sleight of
> hand. Grammar and syntax is flat. Inheritance forms a nested tree. That
> comparison allows you to get away with too much at the expense of
> disparaging one kind of implementation. I'll throw it out on a[/color]
technicality[color=blue]
> as well.[/color]

My point was not about grammar and syntax (which BTW is not so flat: a parse
tree is a tree), it was about natural language and the way we organize our
concepts. Seems like you missed the point completely.
[color=blue]
>
> Could C++ MI be implemented differently? sure, but hindsight, or the[/color]
ability[color=blue]
> to do it again, it wouldn't be done differently, because given the problem
> domain and the context, it works remarkably well. Is there room for
> improvement? always, but that's no reason to go bashing C++. MI got a bad
> name because C++ is syntactically, and otherwise, difficult to say the
> least. MI itself is not a simple concept. Put these two together and it is
> not a walk in the park. C# is a *simpler language compared to c# because a
> lot has been hidden. That approach has allowed the developers to
> re-implement MI in a simpler way - call it interface inheritance or
> whatever, the concept is the same. Notice all what had to change to get MI
> to be easier on the stomach. It's time to show some respect to the elders.
> Without the lessons learned from C++ (c#'s elder), C# would have been[/color]
headed[color=blue]
> for the same hole.[/color]

I'm not bashing C++, nor saying that MI could be implemented more
efficiently in C++. Where did you get this from?

I'm just giving some arguments to explain first why multiple inheritence
between classes is not supported by C# and then why multiple inheritence
between classes may not be such a good idea (based on a linguistic
argument).
[color=blue]
>
> Can of worms for sure.[/color]

I'd rather say that this is an interesting topic, and that the
implementation issues are secondary. The most important issue is whether
multiple inheritance between classes is a desirable language feature or not
(and whether multiple inheritance between interfaces is sufficient or not).
This is a deep issue in language design and it might be interesting to
approach it from unusual angles (like the linguistic one that I am
proposing).

Bruno.
[color=blue]
>
> --
> Regards,
> Alvin Bruney
> Got DotNet? Get it here...
> http://www.networkip.net/dotnet/tidbits/default.htm
> "Bruno Jouhier [MVP]" <bjouhier@clu b-internet.fr> wrote in message
> news:uFml2gIxDH A.560@TK2MSFTNG P11.phx.gbl...[color=green]
> > Several reasons:
> >
> > 1) .NET is strongly inspired from Java, and Java only supports multiple
> > inheritance on interfaces (and Java developers seem to be pretty happy[/color]
> with[color=green]
> > this restriction).
> >
> > 2) A practical reason: multiple inheritance of classes raises more[/color]
> problems[color=green]
> > than multiple inheritance of interfaces. It raises conceptual problems
> > (repeated inheritance, that Eiffel and C++ address differently) but also
> > implementation issues (that C++ managed to solve at the expense of[/color][/color]
strange[color=blue][color=green]
> > hacks, for example pointers being offset when you cast them). Then, my[/color]
> guess[color=green]
> > is that the designers of Java (and .NET) weighed the benefits against[/color][/color]
the[color=blue][color=green]
> > additional complexity (both for the programmer and the implementer of[/color][/color]
the[color=blue][color=green]
> > language) and decided to forget about multiple inheritance of classes[/color][/color]
(the[color=blue][color=green]
> > KISS approach).
> >
> > 3) A more fundamental reason: because natural language works the same[/color][/color]
way,[color=blue][color=green]
> > it favors multiple inheritance of interfaces and single inheritance of
> > classes. If you analyze classes and interfaces from a linguistic[/color]
> standpoint,[color=green]
> > you will quickly reach the conclusion that classes correspond to
> > substantives (nouns) and that interfaces correspond to adjectives (pure
> > specifications that do not impose a particular implementation) . This is
> > obvious if you look at the names of framework level classes and[/color][/color]
interfaces[color=blue][color=green]
> > (many interfaces have "adjective" names, usually xxx-able forms like
> > comparable, cloneable, serializable, convertible, etc., and even[/color]
> substantive[color=green]
> > names like IList, ICollection are adjectives in disguise: list-like,
> > collection-like). And, strangely, our grammars let us combine any number[/color]
> of[color=green]
> > adjectives with a noun and we naturally define a noun as being another[/color]
> noun[color=green]
> > qualified by a set of adjectives (an elephant is a massive gray animal).[/color]
> We[color=green]
> > seldom define a noun as being two other nouns (an elephant is an animal[/color]
> and[color=green]
> > a ?). So, I have the feeling that this restriction that we impose on our
> > artificial languages has actually much deeper roots than we think:
> > naturally, we organize our concepts with single inheritance between[/color][/color]
nouns[color=blue][color=green]
> > and multiple inheritance of adjectives, we don't use multiple[/color][/color]
inheritance[color=blue][color=green]
> > between nouns.
> >
> > Of course, the last point is a bit of a personal theory, but I think[/color][/color]
that[color=blue]
> it[color=green]
> > provides an interesting justification to the design choices made by Java[/color]
> and[color=green]
> > .NET. I got this idea10 years ago, at a time where multiple inheritance[/color]
> was[color=green]
> > a hot topic and I was working on a language project (which did not go
> > through, like 99.99% of these projects). The recent evolution of[/color][/color]
languages[color=blue][color=green]
> > (Java, C#) conforts me in thinking that this point was valid.
> >
> > Bruno.
> >
> >
> > "Matthew Louden" <mattloude@hotm ail.com> a écrit dans le message de
> > news:OKYDUwAxDH A.2000@TK2MSFTN GP11.phx.gbl...[color=darkred]
> > > I want to know why C# doesnt support multiple inheritance? But why we[/color][/color]
> can[color=green][color=darkred]
> > > inherit multiple interfaces instead? I know this is the rule, but I[/color][/color][/color]
dont[color=blue][color=green][color=darkred]
> > > understand why. Can anyone give me some concrete examples?
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Re: why C# can't support multiple inheritance?

> To name three: Too much complexity when base classes occur more than once
in
True, but there are ways to resolve this. Still the issue remains and cannot
be covered. There is complexity.

Complex pointer semantics when casting an instance of[color=blue]
> an MI class to one of the base classes.[/color]

No easy way to handle name[color=blue]
> collisions among base classes.[/color]
Again, what is wrong with the scope resolution operator. That is it's
expressed purpose for being.

this is a function of the language, not MI implementation. MI has to sit
within the bounds of the underlying language. If that language syntax is
overly complex then MI implementation cannot be simple.

I'd like to re-iterate my point because it certainly got lost. MI is an
advanced concept. It isn't trivially implemented. Add to that a language
which, in and of itself is syntactically difficult, to say the least, and
you will have issues. I hedge a bit, that if it had to be re-implemented, it
would be done the same because there are only so many ways to fill a bottle.
What .net and c# has given us is a way to change the shape of the bottle so
that filling it will be more flexible.

--
Regards,
Alvin Bruney
Got DotNet? Get it here...

"Mickey Williams" <my first name at servergeek.com> wrote in message
news:e%23ixx9Lx DHA.3216@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> "Alvin Bruney" <vapor at steaming post office> wrote in message
> news:OXXhdnGxDH A.2396@TK2MSFTN GP09.phx.gbl...[color=green][color=darkred]
> > >when the real problem is the C++ implementation of MI.[/color]
> > What exactly is wrong with the c++ implementation?[/color]
>
> To name three: Too much complexity when base classes occur more than once[/color]
in[color=blue]
> the inheritance tree. Complex pointer semantics when casting an instance[/color]
of[color=blue]
> an MI class to one of the base classes. No easy way to handle name
> collisions among base classes.
>
> --
> Mickey Williams
> Author, "Microsoft Visual C# .NET Core Reference", MS Press
> www.servergeek.com
>
>[/color]

Re: why C# can't support multiple inheritance?

> My post was not a reply to yours, but to the original post. I'm not doing
a
sorry i completely missed the boat on that.

just saying that multiple inheritance between[color=blue]
> classes raises more problems (conceptual and technical) than inheritance
> between interfaces. Do you question that?[/color]
Not at all. Interface inheritance is a better idea. hands down.
[color=blue]
>Seems like you missed the point completely.[/color]
I'm not sure on this one. Already i thought your response was in answer to
mine, so the ship had already sailed on my part. you may be right there.
[color=blue]
> This is a deep issue in language design and it might be interesting to
> approach it from unusual angles (like the linguistic one that I am
> proposing).
>[/color]
It's new. I'll give you that.
--
Regards,
Alvin Bruney
Got DotNet? Get it here...

"Bruno Jouhier [MVP]" <bjouhier@clu b-internet.fr> wrote in message
news:e4HvFEMxDH A.1740@TK2MSFTN GP12.phx.gbl...[color=blue]
> Hi, my comments are in line:
>
> "Alvin Bruney" <vapor at steaming post office> a écrit dans le message de
> news:uqS8lcLxDH A.2452@tk2msftn gp13.phx.gbl...[color=green]
> > I wasn't asking for a comparison between c# and c++. The OP implied that
> > there was a problem with C++ inheritance. I fail to see that so I was
> > wondering what lead him to that conclusion.[/color]
>
> My post was not a reply to yours, but to the original post. I'm not doing[/color]
a[color=blue]
> comparison between C# and C++, just saying that multiple inheritance[/color]
between[color=blue]
> classes raises more problems (conceptual and technical) than inheritance
> between interfaces. Do you question that?
>[color=green]
> >
> > Liking inheritance to grammar is extremely misleading as well, sleight[/color][/color]
of[color=blue][color=green]
> > hand. Grammar and syntax is flat. Inheritance forms a nested tree. That
> > comparison allows you to get away with too much at the expense of
> > disparaging one kind of implementation. I'll throw it out on a[/color]
> technicality[color=green]
> > as well.[/color]
>
> My point was not about grammar and syntax (which BTW is not so flat: a[/color]
parse[color=blue]
> tree is a tree), it was about natural language and the way we organize our
> concepts. Seems like you missed the point completely.
>[color=green]
> >
> > Could C++ MI be implemented differently? sure, but hindsight, or the[/color]
> ability[color=green]
> > to do it again, it wouldn't be done differently, because given the[/color][/color]
problem[color=blue][color=green]
> > domain and the context, it works remarkably well. Is there room for
> > improvement? always, but that's no reason to go bashing C++. MI got a[/color][/color]
bad[color=blue][color=green]
> > name because C++ is syntactically, and otherwise, difficult to say the
> > least. MI itself is not a simple concept. Put these two together and it[/color][/color]
is[color=blue][color=green]
> > not a walk in the park. C# is a *simpler language compared to c# because[/color][/color]
a[color=blue][color=green]
> > lot has been hidden. That approach has allowed the developers to
> > re-implement MI in a simpler way - call it interface inheritance or
> > whatever, the concept is the same. Notice all what had to change to get[/color][/color]
MI[color=blue][color=green]
> > to be easier on the stomach. It's time to show some respect to the[/color][/color]
elders.[color=blue][color=green]
> > Without the lessons learned from C++ (c#'s elder), C# would have been[/color]
> headed[color=green]
> > for the same hole.[/color]
>
> I'm not bashing C++, nor saying that MI could be implemented more
> efficiently in C++. Where did you get this from?
>
> I'm just giving some arguments to explain first why multiple inheritence
> between classes is not supported by C# and then why multiple inheritence
> between classes may not be such a good idea (based on a linguistic
> argument).
>[color=green]
> >
> > Can of worms for sure.[/color]
>
> I'd rather say that this is an interesting topic, and that the
> implementation issues are secondary. The most important issue is whether
> multiple inheritance between classes is a desirable language feature or[/color]
not[color=blue]
> (and whether multiple inheritance between interfaces is sufficient or[/color]
not).[color=blue]
> This is a deep issue in language design and it might be interesting to
> approach it from unusual angles (like the linguistic one that I am
> proposing).
>
> Bruno.
>[color=green]
> >
> > --
> > Regards,
> > Alvin Bruney
> > Got DotNet? Get it here...
> > http://www.networkip.net/dotnet/tidbits/default.htm
> > "Bruno Jouhier [MVP]" <bjouhier@clu b-internet.fr> wrote in message
> > news:uFml2gIxDH A.560@TK2MSFTNG P11.phx.gbl...[color=darkred]
> > > Several reasons:
> > >
> > > 1) .NET is strongly inspired from Java, and Java only supports[/color][/color][/color]
multiple[color=blue][color=green][color=darkred]
> > > inheritance on interfaces (and Java developers seem to be pretty happy[/color]
> > with[color=darkred]
> > > this restriction).
> > >
> > > 2) A practical reason: multiple inheritance of classes raises more[/color]
> > problems[color=darkred]
> > > than multiple inheritance of interfaces. It raises conceptual problems
> > > (repeated inheritance, that Eiffel and C++ address differently) but[/color][/color][/color]
also[color=blue][color=green][color=darkred]
> > > implementation issues (that C++ managed to solve at the expense of[/color][/color]
> strange[color=green][color=darkred]
> > > hacks, for example pointers being offset when you cast them). Then, my[/color]
> > guess[color=darkred]
> > > is that the designers of Java (and .NET) weighed the benefits against[/color][/color]
> the[color=green][color=darkred]
> > > additional complexity (both for the programmer and the implementer of[/color][/color]
> the[color=green][color=darkred]
> > > language) and decided to forget about multiple inheritance of classes[/color][/color]
> (the[color=green][color=darkred]
> > > KISS approach).
> > >
> > > 3) A more fundamental reason: because natural language works the same[/color][/color]
> way,[color=green][color=darkred]
> > > it favors multiple inheritance of interfaces and single inheritance of
> > > classes. If you analyze classes and interfaces from a linguistic[/color]
> > standpoint,[color=darkred]
> > > you will quickly reach the conclusion that classes correspond to
> > > substantives (nouns) and that interfaces correspond to adjectives[/color][/color][/color]
(pure[color=blue][color=green][color=darkred]
> > > specifications that do not impose a particular implementation) . This[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > obvious if you look at the names of framework level classes and[/color][/color]
> interfaces[color=green][color=darkred]
> > > (many interfaces have "adjective" names, usually xxx-able forms like
> > > comparable, cloneable, serializable, convertible, etc., and even[/color]
> > substantive[color=darkred]
> > > names like IList, ICollection are adjectives in disguise: list-like,
> > > collection-like). And, strangely, our grammars let us combine any[/color][/color][/color]
number[color=blue][color=green]
> > of[color=darkred]
> > > adjectives with a noun and we naturally define a noun as being another[/color]
> > noun[color=darkred]
> > > qualified by a set of adjectives (an elephant is a massive gray[/color][/color][/color]
animal).[color=blue][color=green]
> > We[color=darkred]
> > > seldom define a noun as being two other nouns (an elephant is an[/color][/color][/color]
animal[color=blue][color=green]
> > and[color=darkred]
> > > a ?). So, I have the feeling that this restriction that we impose on[/color][/color][/color]
our[color=blue][color=green][color=darkred]
> > > artificial languages has actually much deeper roots than we think:
> > > naturally, we organize our concepts with single inheritance between[/color][/color]
> nouns[color=green][color=darkred]
> > > and multiple inheritance of adjectives, we don't use multiple[/color][/color]
> inheritance[color=green][color=darkred]
> > > between nouns.
> > >
> > > Of course, the last point is a bit of a personal theory, but I think[/color][/color]
> that[color=green]
> > it[color=darkred]
> > > provides an interesting justification to the design choices made by[/color][/color][/color]
Java[color=blue][color=green]
> > and[color=darkred]
> > > .NET. I got this idea10 years ago, at a time where multiple[/color][/color][/color]
inheritance[color=blue][color=green]
> > was[color=darkred]
> > > a hot topic and I was working on a language project (which did not go
> > > through, like 99.99% of these projects). The recent evolution of[/color][/color]
> languages[color=green][color=darkred]
> > > (Java, C#) conforts me in thinking that this point was valid.
> > >
> > > Bruno.
> > >
> > >
> > > "Matthew Louden" <mattloude@hotm ail.com> a écrit dans le message de
> > > news:OKYDUwAxDH A.2000@TK2MSFTN GP11.phx.gbl...
> > > > I want to know why C# doesnt support multiple inheritance? But why[/color][/color][/color]
we[color=blue][color=green]
> > can[color=darkred]
> > > > inherit multiple interfaces instead? I know this is the rule, but I[/color][/color]
> dont[color=green][color=darkred]
> > > > understand why. Can anyone give me some concrete examples?
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]