why C# can't support multiple inheritance?

[Matthew Louden]

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?

[William Stacey]

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" <ma*******@hotmail.com> wrote in message
news:OK**************@TK2MSFTNGP11.phx.gbl...

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?

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

-----Original Message-----
I want to know why C# doesnt support multiple inheritance? But why we caninherit multiple interfaces instead? I know this is the rule, but I dontunderstand why. Can anyone give me some concrete examples?
.

[Rob Teixeira [MVP]]

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" <ma*******@hotmail.com> wrote in message
news:OK**************@TK2MSFTNGP11.phx.gbl...

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?

[Mickey Williams]

"Matthew Louden" <ma*******@hotmail.com> wrote in message
news:OK**************@TK2MSFTNGP11.phx.gbl...

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?

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
www.servergeek.com

[Alvin Bruney]

>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...
http://www.networkip.net/dotnet/tidbits/default.htm
"Mickey Williams" <my first name at servergeek.com> wrote in message
news:Og**************@tk2msftngp13.phx.gbl...

"Matthew Louden" <ma*******@hotmail.com> wrote in message
news:OK**************@TK2MSFTNGP11.phx.gbl...

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?
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
www.servergeek.com

[Bruno Jouhier [MVP]]

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" <ma*******@hotmail.com> a écrit dans le message de
news:OK**************@TK2MSFTNGP11.phx.gbl...

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?

[Hung Jung Lu]

"Matthew Louden" <ma*******@hotmail.com> wrote in message news:<OK**************@TK2MSFTNGP11.phx.gbl>...

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?

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+delegation 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

[Alvin Bruney]

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...
http://www.networkip.net/dotnet/tidbits/default.htm
"Bruno Jouhier [MVP]" <bj******@club-internet.fr> wrote in message
news:uF*************@TK2MSFTNGP11.phx.gbl...

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" <ma*******@hotmail.com> a écrit dans le message de
news:OK**************@TK2MSFTNGP11.phx.gbl...

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?

[Mickey Williams]

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

"Matthew Louden" <ma*******@hotmail.com> wrote in message news:<OK**************@TK2MSFTNGP11.phx.gbl>...
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:

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
www.servergeek.com

[Mickey Williams]

"Alvin Bruney" <vapor at steaming post office> wrote in message
news:OX**************@TK2MSFTNGP09.phx.gbl...

when the real problem is the C++ implementation of MI.

What exactly is wrong with the c++ implementation?

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
www.servergeek.com

[Alvin Bruney]

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:

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.

--
Regards,
Alvin Bruney
Got DotNet? Get it here...
http://www.networkip.net/dotnet/tidbits/default.htm
"Mickey Williams" <my first name at servergeek.com> wrote in message
news:el**************@TK2MSFTNGP09.phx.gbl... "Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e**************************@posting.google.c om...

"Matthew Louden" <ma*******@hotmail.com> wrote in message news:<OK**************@TK2MSFTNGP11.phx.gbl>...

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:

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
www.servergeek.com

[Bruno Jouhier [MVP]]

Hi, my comments are in line:

"Alvin Bruney" <vapor at steaming post office> a écrit dans le message de
news:uq**************@tk2msftngp13.phx.gbl...

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

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

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

Can of worms for sure.
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.

--
Regards,
Alvin Bruney
Got DotNet? Get it here...
http://www.networkip.net/dotnet/tidbits/default.htm
"Bruno Jouhier [MVP]" <bj******@club-internet.fr> wrote in message
news:uF*************@TK2MSFTNGP11.phx.gbl...

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" <ma*******@hotmail.com> a écrit dans le message de
news:OK**************@TK2MSFTNGP11.phx.gbl...

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?

[Alvin Bruney]

> 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

an MI class to one of the base classes.
No easy way to handle name collisions among base classes. 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...
http://www.networkip.net/dotnet/tidbits/default.htm
"Mickey Williams" <my first name at servergeek.com> wrote in message
news:e%****************@TK2MSFTNGP11.phx.gbl... "Alvin Bruney" <vapor at steaming post office> wrote in message
news:OX**************@TK2MSFTNGP09.phx.gbl...

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

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
www.servergeek.com

[Alvin Bruney]

> 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

classes raises more problems (conceptual and technical) than inheritance
between interfaces. Do you question that? Not at all. Interface inheritance is a better idea. hands down.
Seems like you missed the point completely. 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.
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).
It's new. I'll give you that.
--
Regards,
Alvin Bruney
Got DotNet? Get it here...
http://www.networkip.net/dotnet/tidbits/default.htm
"Bruno Jouhier [MVP]" <bj******@club-internet.fr> wrote in message
news:e4**************@TK2MSFTNGP12.phx.gbl... Hi, my comments are in line:

"Alvin Bruney" <vapor at steaming post office> a écrit dans le message de
news:uq**************@tk2msftngp13.phx.gbl...

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

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.

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.

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.

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

Can of worms for sure.

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.

--
Regards,
Alvin Bruney
Got DotNet? Get it here...
http://www.networkip.net/dotnet/tidbits/default.htm
"Bruno Jouhier [MVP]" <bj******@club-internet.fr> wrote in message
news:uF*************@TK2MSFTNGP11.phx.gbl...

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" <ma*******@hotmail.com> a écrit dans le message de
news:OK**************@TK2MSFTNGP11.phx.gbl...
> 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?
>
>

[Hung Jung Lu]

"Alvin Bruney" <vapor at steaming post office> wrote in message news:<#3**************@TK2MSFTNGP11.phx.gbl>...

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:

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.

I think Mickey Williams is talking from real-life experience, whereas
you are just guessing it as an exercise. :)

Very often, in the context of generic programming, you actually want
to access the same variable, from both A and B. That is why in C#/Java
and sometimes even C++ people often write property accessor methods
(getters/setters) (Though C++ has templates for generic programming,
and that helps.) This *is* an issue with MI for some languages.

For instance, A might have a method (I am using pseudo code here)

void A::Triple() {
this.x = 3*this.x;
}

B might have a method

void B::Increment() {
this.x += 1;
}

C inherits A and B. Often you want both A and B to access the same
memory slot x. This type of MI is usually known as Mix-In classes. You
add functionality to an existing class, but often you access the data
of the original class.

I don't know Eiffel. But any language that does not support virtual
data fields will have problem and will require extra work.

In languages with virtual data fields, this type of Mix-In classes is
piece of cake and routinely used.

regards,

Hung Jung

[Rob Teixeira [MVP]]

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

Very often, in the context of generic programming, you actually want
to access the same variable, from both A and B. That is why in C#/Java
and sometimes even C++ people often write property accessor methods
(getters/setters)
Inherited fields are automatically accessable down the inheritance tree as
it is. You do not require accessor/mutator members for this.
The real reason for accessor/mutator members is to control access and
implementation details to a field, that alone would have no protection
against unwanted access or damaging value changes.
(Though C++ has templates for generic programming,
and that helps.) This *is* an issue with MI for some languages.

The next version of .NET will also have support for generics, but I'm not
clear on how this dramatically changes access to the same variable from
different types. (?)

-Rob Teixeira [MVP]

[Alvin Bruney]

> I think Mickey Williams is talking from real-life experience, whereas

you are just guessing it as an exercise. :) what's the point of this? Even if I were still in school, does it make my
point less valid?
Very often, in the context of generic programming, you actually want
to access the same variable, from both A and B. code like what you produced is the reason why folks take a dump on MI.
You've created a hierarchy where, according to you, both properties are so
tightly coupled to each other that calling functions out of order results in
unpredictable results.
Very often, in the context of generic programming, you actually want
to access the same variable, from both A and B. That is why in C#/Java
and sometimes even C++ people often write property accessor methods That is completely wrong and unfounded. Inheritance, in and of itself,
automatigically makes that information available to derived classes except
where they are explicitly withheld as in the case of access specifiers like
private, and to some extent protected tags which apply to classes outside
the hierarchy.
Very often, in the context of generic programming, you actually want
to access the same variable, from both A and B. When you subvert the inheritance mechanism into a distilled version of
global variables (which is what you are proposing), you compromise the
integrity of the heirarchy. Put another way, I can't possibly see the
benefit of removing the protection of a class variable and reducing it to a
global variable where you want access the same memory slot by different
classes. This kind of programming leads to improperly behaved code and
maintenance nightmares because one cannot easily identify which thread
caused the change, since any class could have modified the same slot at any
point in time.

Anyway, I've got a final to study for.

--
Regards,
Alvin Bruney
Got DotNet? Get it here...
http://www.networkip.net/dotnet/tidbits/default.htm
"Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e**************************@posting.google.c om... "Alvin Bruney" <vapor at steaming post office> wrote in message news:<#3**************@TK2MSFTNGP11.phx.gbl>...

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:

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.

I think Mickey Williams is talking from real-life experience, whereas
you are just guessing it as an exercise. :)

That is why in C#/Java and sometimes even C++ people often write property accessor methods
(getters/setters) (Though C++ has templates for generic programming,
and that helps.) This *is* an issue with MI for some languages.

For instance, A might have a method (I am using pseudo code here)

void A::Triple() {
this.x = 3*this.x;
}

B might have a method

void B::Increment() {
this.x += 1;
}

C inherits A and B. Often you want both A and B to access the same
memory slot x. This type of MI is usually known as Mix-In classes. You
add functionality to an existing class, but often you access the data
of the original class.

I don't know Eiffel. But any language that does not support virtual
data fields will have problem and will require extra work.

In languages with virtual data fields, this type of Mix-In classes is
piece of cake and routinely used.

regards,

Hung Jung

[Hung Jung Lu]

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message news:<O9**************@TK2MSFTNGP12.phx.gbl>...

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

Very often, in the context of generic programming, you actually want
to access the same variable, from both A and B. That is why in C#/Java
and sometimes even C++ people often write property accessor methods
(getters/setters)
Inherited fields are automatically accessable down the inheritance tree as
it is. You do not require accessor/mutator members for this.
The real reason for accessor/mutator members is to control access and
implementation details to a field, that alone would have no protection
against unwanted access or damaging value changes.

Erh? You got the direction wrong. It's not down the tree, it's up the
tree.

First of all, you are talking about accessors in general. We are
talking about accessors in MI.

Secondly, in Mix-In class methods, you do not want to access parent
data fields, you want to access child data fields. That's the beauty
of it. I guess you just jumped in without having read my points about
virtual data fields.

Ask yourself: how can a parent class method access the data fields of
a child class? A first answer is: you CAN'T. When you designed the
parent class, you had zero information about the child class. In
statically typed languages like C++/Java/C#, there is simply no way of
accessing child data fields directly. These languages don't support
virtual data fields.

A more careful answer is that, there are different devices that allows
you to access child data attributes. C++/Java/C# do NOT support
virtual data fields, but they do support virtual class methods. So,
you implement a getter/setter, and voila, you can now access data
fields of children classes.

So far so good for C++, until you are hit with absence of MI class
inheritance in C#/Java. You then scratch your head and ask yourself:
"How in the world can I write a Mix-In class?"

Well, you can still do it. If the Mix-In class B is specifically
designed to enhance an existing class A, your methods in B can take
instance of A as the first argument. You then do
containment+delegation to expose the B interface for the new class.

We are getting into the Voodoo magic territory. Hold on to your seat.

The next step is, what if your Mix-In class B is generic, that is,
non-specific to class A?

You can't do it in C# last year. But you can do it now with the new
generics.
The next version of .NET will also have support for generics, but I'm not
clear on how this dramatically changes access to the same variable from
different types. (?)

With generics, your Mix-In classes can be applied to all classes that
expose the necessary accessor methods (or properties in C#). You need
to declare the necessary interfaces for that purpose. Only after you
have made your Mix-In generic, can you call it a true Mix-In.

All these things are voodoo magic in C#/Java. (And I am sure I have
lost 95% of the audience.) But in dynamically typed languages like
Python or Ruby, these are banalities not even worth a discussion.
Sure, under the hood they are quite equivalent. But in C#/Java you (a
human) are basically doing the job that a good compiler (a machine)
should do.

After you are laboriously and happily done with using class MI and
factoring out the common code spots of your program, you would
probably cry again when you need to make changes. MI is just too hard
to use directly. In C#/Java, a better approach is to use a code
generator, and just let the common code spread all over different
classes. Sure, this is code bloating (much like templates in C++,
which are just macros). But given the shortcomings of C#/Java, you
don't have much a choice.

If you have gotten completely lost, don't worry. You will understand
it the day you need to implement Mix-In classes by yourself.

regards,

Hung Jung

[Alvin Bruney]

>Secondly, in Mix-In class methods

"How in the world can I write a Mix-In class?"
Is that what this is about? You are upset because C# didn't borrow this
*neat feature? That there is no native support for doing this? You've
provided no argument to prove that this is needed. First of all, accessing
class data fields is a no no. If a parent wants to access a child's member
or any class for that matter, the child has methods to allow that, otherwise
it doesn't. What difference does it make if this is supported internal with
special syntax. The effect is the same.
And I am sure I have
lost 95% of the audience. frankly your aloof attitude is what is losing me
If you have gotten completely lost, don't worry. You will understand
it the day you need to implement Mix-In classes by yourself.
This is a place of learning and exchange of ideas. If you think you are
better or the sharpest tool in the shed, then why do you come in here?
surely, you must be wasting your time because we are all students in here -
95% of us being lost on what you said.

I'm done here. Ignorance lives among us.

--

Regards,

Alvin Bruney

Got DotNet? Get it here

"Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e**************************@posting.google.c om... "Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message

news:<O9**************@TK2MSFTNGP12.phx.gbl>...

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

Very often, in the context of generic programming, you actually want
to access the same variable, from both A and B. That is why in C#/Java
and sometimes even C++ people often write property accessor methods
(getters/setters)

Inherited fields are automatically accessable down the inheritance tree as it is. You do not require accessor/mutator members for this.
The real reason for accessor/mutator members is to control access and
implementation details to a field, that alone would have no protection
against unwanted access or damaging value changes.

Erh? You got the direction wrong. It's not down the tree, it's up the
tree.

First of all, you are talking about accessors in general. We are
talking about accessors in MI.

Secondly, in Mix-In class methods, you do not want to access parent
data fields, you want to access child data fields. That's the beauty
of it. I guess you just jumped in without having read my points about
virtual data fields.

Ask yourself: how can a parent class method access the data fields of
a child class? A first answer is: you CAN'T. When you designed the
parent class, you had zero information about the child class. In
statically typed languages like C++/Java/C#, there is simply no way of
accessing child data fields directly. These languages don't support
virtual data fields.

A more careful answer is that, there are different devices that allows
you to access child data attributes. C++/Java/C# do NOT support
virtual data fields, but they do support virtual class methods. So,
you implement a getter/setter, and voila, you can now access data
fields of children classes.

So far so good for C++, until you are hit with absence of MI class
inheritance in C#/Java. You then scratch your head and ask yourself:
"How in the world can I write a Mix-In class?"

Well, you can still do it. If the Mix-In class B is specifically
designed to enhance an existing class A, your methods in B can take
instance of A as the first argument. You then do
containment+delegation to expose the B interface for the new class.

We are getting into the Voodoo magic territory. Hold on to your seat.

The next step is, what if your Mix-In class B is generic, that is,
non-specific to class A?

You can't do it in C# last year. But you can do it now with the new
generics.

The next version of .NET will also have support for generics, but I'm not clear on how this dramatically changes access to the same variable from
different types. (?)

With generics, your Mix-In classes can be applied to all classes that
expose the necessary accessor methods (or properties in C#). You need
to declare the necessary interfaces for that purpose. Only after you
have made your Mix-In generic, can you call it a true Mix-In.

All these things are voodoo magic in C#/Java. (And I am sure I have
lost 95% of the audience.) But in dynamically typed languages like
Python or Ruby, these are banalities not even worth a discussion.
Sure, under the hood they are quite equivalent. But in C#/Java you (a
human) are basically doing the job that a good compiler (a machine)
should do.

After you are laboriously and happily done with using class MI and
factoring out the common code spots of your program, you would
probably cry again when you need to make changes. MI is just too hard
to use directly. In C#/Java, a better approach is to use a code
generator, and just let the common code spread all over different
classes. Sure, this is code bloating (much like templates in C++,
which are just macros). But given the shortcomings of C#/Java, you
don't have much a choice.

If you have gotten completely lost, don't worry. You will understand
it the day you need to implement Mix-In classes by yourself.

regards,

Hung Jung

[Rob Teixeira [MVP]]

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

Erh? You got the direction wrong. It's not down the tree, it's up the
tree.
Depends which direction the tree is pointing ;-)
Secondly, in Mix-In class methods, you do not want to access parent
data fields, you want to access child data fields. That's the beauty
of it. I guess you just jumped in without having read my points about
virtual data fields.
I read it, but your context got lost in the noise of the other posts.
Ask yourself: how can a parent class method access the data fields of
a child class? A first answer is: you CAN'T. When you designed the
parent class, you had zero information about the child class. In
statically typed languages like C++/Java/C#, there is simply no way of
accessing child data fields directly. These languages don't support
virtual data fields.
Correct, because these languages abide by the tenet that while it's cheap to
access a field of a different type, you should only directly access a field
of your own type, which prevents inadvertant and unwanted value updates and
reads that can cause issues with the implementation details of the other
type. This, in my opinion, is the biggest risk with multiple inheritance
(and as I said, i'm not entirely opposed to MI either).
So far so good for C++, until you are hit with absence of MI class
inheritance in C#/Java. You then scratch your head and ask yourself:
"How in the world can I write a Mix-In class?"
If you abide by the basic definition of a Mix-In class, which is an abstract
class designed to be blended with another type through MI in order to extend
its members, then I think you will find it isn't such a stretch after all.
That in fact, Mix-In classes are just syntactical sugar for alternate
structural mechanisms.
Well, you can still do it. If the Mix-In class B is specifically
designed to enhance an existing class A, your methods in B can take
instance of A as the first argument. You then do
containment+delegation to expose the B interface for the new class.
Yep.
All these things are voodoo magic in C#/Java. (And I am sure I have
lost 95% of the audience.) But in dynamically typed languages like
Python or Ruby, these are banalities not even worth a discussion.
Sure, under the hood they are quite equivalent. But in C#/Java you (a
human) are basically doing the job that a good compiler (a machine)
should do.
While I don't disagree with you, I think the underlying principal is that
the designers of these languages came to the conclusion that the "good
compiler" is allowing programmers to do things that perhaps shouldn't be
done, or at the very least create a recipe for danger too easily. Whether
one agrees with that decision or not is a matter of personal opinion.
Personally, I think there are far better uses for MI than Mix-In classes,
but in the C#/Java world, we simply have to live without it. Now, having had
to maintain programs that were falling apart at the seams because of
convoluted inheritance trees, I can understand the concern, though I haven't
completely decided that I agree 100% or not with the language designers -
especially since, if you forget the gritty internal details and think about
the overall design structure, there certainly are ways to still accomplish
the underlying goals.
After you are laboriously and happily done with using class MI and
factoring out the common code spots of your program, you would
probably cry again when you need to make changes. MI is just too hard
to use directly.
Yes. And therein lies a good deal of the pain :-)
The test of any object model is it's ability to be maintained and extended
AFTER the initial implementation, and MI *can* easily cause that to collapse
quickly. Note that I said *can* because some people insist on preaching that
MI is evil, like it's guaranteed to break things, and I'm certainly not
advocating that line of thought.
In C#/Java, a better approach is to use a code
generator, and just let the common code spread all over different
classes. Sure, this is code bloating (much like templates in C++,
which are just macros). But given the shortcomings of C#/Java, you
don't have much a choice.

Hm, I'm not entirely convinced that's the only choice. And having lived with
deficient code generators before, I'll take my chances with something else
(even if it is a little more manual) :-)
But on the flipside, I can honestly say that I haven't gone through
withdrawl over the lack of MI either.

-Rob Teixeira [MVP]

[Mickey Williams]

Going back to the original poster - this debate is the perfect illustration
as to why MI is not in the CLR.

"Alvin Bruney" <vapor at steaming post office> wrote in message
news:Oc**************@TK2MSFTNGP12.phx.gbl...

True, but there are ways to resolve this. Still the issue remains and cannot be covered. There is complexity.

I grant that there is complexity when using C++ and MI. But in my opinion,
you have apparently *only* used MI in C++. If you have never used a language
that properly implements MI, it is going to be very very difficult for you
to convince me that my experience with Eiffel's MI is incorrect. Let me put
it this way - MI is so easy to use in Eiffel that there are *no* non-trivial
Eiffel systems that fail to use it. It's one of the core idioms in the
standard libraries. It is taught very early in the official Eiffel hands-on
course. Experience with Eiffel as a teaching language shows that MI (in
Eiffel anyway) is really not a difficult concept to grasp and leverage.

Now, the question is - if Eiffel can do it correctly, why is it that *you*
think it's a general OO problem, rather than a language issue? I think the
C# language and CLR teams are smart enough to see what works and what
doesn't, and if they do implement MI, I'm hoping that it looks more like the
Eiffel model than the C++ model.

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

[Alvin Bruney]

>But in my opinion,

you have apparently *only* used MI in C++ You are spot on there. But according to stroustrup, that's where C++
borrowed inheritance from anyway. Vulcan logic dictates that either
complexity was added in. OR, it's implementation was complex to start with.
I've never worked with eiffel, so i'll take your word for it that it is
trivial implemented though having used it in C++ it seems contrary since
that is where it came from.
If you have never used a language
that properly implements MI, Again, the C++ bashing. Why do you think it isn't properly implemented? It
works well for those who care enough to understand how to use it. Most
people do not spend the time to understand MI. Couple that with poor
application design, and MI becomes a mess. But you cannot lay blame on C++
for that? Or is that what you are suggesting?
Now, the question is - if Eiffel can do it correctly, why is it that *you*
think it's a general OO problem, rather than a language issue? That wasn't me. What I said was

"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'm willing to let that misquote slide
--
Regards,
Alvin Bruney
Got DotNet? Get it here
http://home.networkip.net/dotnet/tidbits/default.htm
"Mickey Williams" <my first name at servergeek.com> wrote in message
news:O4**************@TK2MSFTNGP09.phx.gbl...
Going back to the original poster - this debate is the perfect illustration as to why MI is not in the CLR.

"Alvin Bruney" <vapor at steaming post office> wrote in message
news:Oc**************@TK2MSFTNGP12.phx.gbl...

True, but there are ways to resolve this. Still the issue remains and cannot

be covered. There is complexity.

I grant that there is complexity when using C++ and MI. But in my opinion,
you have apparently *only* used MI in C++. If you have never used a

language that properly implements MI, it is going to be very very difficult for you
to convince me that my experience with Eiffel's MI is incorrect. Let me put it this way - MI is so easy to use in Eiffel that there are *no* non-trivial Eiffel systems that fail to use it. It's one of the core idioms in the
standard libraries. It is taught very early in the official Eiffel hands-on course. Experience with Eiffel as a teaching language shows that MI (in
Eiffel anyway) is really not a difficult concept to grasp and leverage.

Now, the question is - if Eiffel can do it correctly, why is it that *you*
think it's a general OO problem, rather than a language issue? I think the
C# language and CLR teams are smart enough to see what works and what
doesn't, and if they do implement MI, I'm hoping that it looks more like the Eiffel model than the C++ model.

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