Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Multiple inheritance in C# and .NET platform ?

35 views
Skip to first unread message

Volkan Arslan

unread,
Sep 16, 2000, 3:00:00 AM9/16/00
to

I would be interested, why the .NET platform (common type system of .NET
platform and the reference language C# of .NET) don't support multiple
inheritance. I know that C# supports multiple interface inheritance, but
this is definitively not the same as multiple inheritance. This point is
very interesting, as there are languages like C++ and Eiffel (and of
course other languages) which support multiple inheritance. In case of
Eiffel multiple inheritance is supported very elegantly. And also most
OODBMS (like Matisse, Versant, Poet, ...) directly support multiple
inheritance. So the question is why Microsoft has decided not to support
multiple inheritance.

I also think, that it is not too late for Microsoft to extend the common
type system of the .NET platform (and of course C#) with multiple
inheritance. Eiffel would be a very good reference to look how multiple
inheritance can be integrated into an OO language. At any rate, it would
be better to include multiple inherintance now, than later.

The above said can also be applied to genericity, although I have heard
rumors that Microsoft will support genericity in C#. Again the languages
C++ and Eiffel and most OODBMS support this mechanism quite well,
especially Eiffel with its constrained genericity.

What does other people think about this topic ? Personally I think, that
true multiple inheritance and genericity are really very important in an
OO context, and the .NET platform (which will very likely influence
the future of the software industry) should directly support these two
very important mechanisms.

Best regards,

Volkan Arslan

Volkan Arslan

unread,
Sep 16, 2000, 3:00:00 AM9/16/00
to

Jay Glynn

unread,
Sep 16, 2000, 3:00:00 AM9/16/00
to
I think that the general reason is that multiple inheritance add to much
complexity for very little gain. In other words it can be a handy feature,
but is it ***really*** needed. That is an oversimplification, but that's the
impression that I got when the question was asked at PDC.

"Volkan Arslan" <Volkan...@gmx.net> wrote in message
news:39C36C0D...@gmx.net...

Klaus Michelsen

unread,
Sep 16, 2000, 12:23:15 PM9/16/00
to
I don't know the reasons for why MS is not including multiple (class)
inheritance (MI) , but here is my opinion about it:

MI seems great on the surface, however it is saturated with subtleties which
makes proper design difficult, some of these are:

1) Two (or more) base classes may contain methods that have the same
signature but different implementations...which one should be chosen? or
they may have two identically named fields...which one should be used? If
many classes are involved, things could get ugly and bugs could appear that
would be hard to trace. Interfaces solve this problem in an elegant way.

2) Overhead is added to both the compiler and the run-time system trying to
sort out the grey areas.

Overall I'm very happy that MS didn't allow multiple inheritance (and hope
they are not going to include it), I believe multiple (class) inheritance
can effectively be substituted by using a combination of single class
inheritance and allowing the implementation of many interfaces.

Klaus


"Volkan Arslan" <Volkan...@gmx.net> wrote in message

news:39C36EF4...@gmx.net...

Eirik Mangseth

unread,
Sep 17, 2000, 3:00:00 AM9/17/00
to

"Klaus Michelsen" <dri...@ozemail.com.au> wrote in message
news:KfMw5.18743$cr3.4...@ozemail.com.au...

> I don't know the reasons for why MS is not including multiple (class)
> inheritance (MI) , but here is my opinion about it:
>
> MI seems great on the surface, however it is saturated with subtleties
which
> makes proper design difficult, some of these are:
>
> 1) Two (or more) base classes may contain methods that have the same
> signature but different implementations...which one should be chosen? or
> they may have two identically named fields...which one should be used? If
> many classes are involved, things could get ugly and bugs could appear
that
> would be hard to trace. Interfaces solve this problem in an elegant way.

With lots and lots of code duplication to go along with it.

>
> 2) Overhead is added to both the compiler and the run-time system trying
to
> sort out the grey areas.

Most Eiffel compilers (perhaps all) don't have problems with this.

Read Object-oriented Software Construction 2nd Edition for an example how
this
can be achieved quite elegantly. Or even better, get your hands on an Eiffel
compiler
and see for yourself. After 15 years of Eiffel I'm getting a bit tired of
seeing how
people base their views on C++'s version of MI which is quite horrid.


>
> Overall I'm very happy that MS didn't allow multiple inheritance (and hope
> they are not going to include it), I believe multiple (class) inheritance
> can effectively be substituted by using a combination of single class
> inheritance and allowing the implementation of many interfaces.

Again, programming in both Eiffel and Java has shown me how badly
Java's interface mechanism compares to the well-defined, well-controlled
MI-mechanism that one finds in Eiffel.

Sorry guys, MI is *NOT* bad, but like any other fairly advanced concept
it requires some thought up-front, but that's a trait of good software
engineering in
general.

So, I hope the .NET *common run-time* will include support for MI and then
leave
it to the language designers whether they wish to utilize this or not. I'm
quite happy
with C# not having MI, but the lack of MI in the common run-time sort of
reduces
some of Eiffel's great functionality and IMHO a VM should be at least try to
implement
a super-set of the features found in the languages using its services.

Eirik Mangseth
Stockpoint Nordic AS
Lysaker, Norway

"If I can't Eiffel in heaven, I won't go"

Ian Joyner

unread,
Sep 17, 2000, 3:00:00 AM9/17/00
to
in article KfMw5.18743$cr3.4...@ozemail.com.au, Klaus Michelsen wrote:

> I don't know the reasons for why MS is not including multiple (class)
> inheritance (MI) , but here is my opinion about it:
>
> MI seems great on the surface, however it is saturated with subtleties which
> makes proper design difficult, some of these are:
>
> 1) Two (or more) base classes may contain methods that have the same
> signature but different implementations...which one should be chosen? or
> they may have two identically named fields...which one should be used? If
> many classes are involved, things could get ugly and bugs could appear that
> would be hard to trace. Interfaces solve this problem in an elegant way.
>
> 2) Overhead is added to both the compiler and the run-time system trying to
> sort out the grey areas.
>
> Overall I'm very happy that MS didn't allow multiple inheritance (and hope
> they are not going to include it), I believe multiple (class) inheritance
> can effectively be substituted by using a combination of single class
> inheritance and allowing the implementation of many interfaces.

No, for practical software reuse, you need implementation MI, not just
interface MI. With just interface MI, you are forced to implement at least a
default routine in all concrete subclasses. With implementation MI, you can
put this in the parent class.

If you really don't like implementation MI, then in a language with
implementation MI, you could restrict yourself to interface MI, but it will
quickly become obvious why this is a silly restriction.

Also most people's problems with MI comes from C++ experience. That's just
C++, things don't have to be that way, but C++ makes a mess of most things,
so don't judge MI by C++.

In reality, C# offers very little over Java, the best thing about .NET is
that it allows multiple languages so the shortcomings of C# can be stepped
around, whereas with Java this is more difficult.
--
Ian Joyner
i.jo...@acm.org http://homepages.tig.com.au/~ijoyner/

Eiffel for Macintosh
http://www.object-tools.com/products/eiffel-s/index.html

TOOLS Pacific 20-23 Nov 2000: http://www.socs.uts.edu.au/tools/

Objects Unencapsulated -- The book (also available in Japanese)
http://www.prenhall.com/allbooks/ptr_0130142697.html
http://efsa.sourceforge.net/cgi-bin/view/Main/ObjectsUnencapsulated


Charles Hixson

unread,
Sep 17, 2000, 3:00:00 AM9/17/00
to
Ian Joyner wrote:

> ...


> No, for practical software reuse, you need implementation MI, not just
> interface MI. With just interface MI, you are forced to implement at least a
> default routine in all concrete subclasses. With implementation MI, you can
> put this in the parent class.
>
> If you really don't like implementation MI, then in a language with
> implementation MI, you could restrict yourself to interface MI, but it will
> quickly become obvious why this is a silly restriction.

> ...

This makes the assumption that the experiencer has previously experienced a
better implementation. If, OTOH, his prior experience is Java and C++, then the
preference for single inheritance becomes quite reasonable.

Unfortunately, multiple inheritence is implemented properly in only a few
languages. I feel that these are Eiffel, Lisp and Ada (Ada thinks of itself as
being single inheritance, but I'm not convinced ... their semantics are so
different, however, that it probably isn't strictly comparable). These are all
languages that few have experienced.
Python, also, has a very interesting implementation of MI. And I believe that
Ruby has a similar one. These languages are more common, but they are normally
closely tied to C, so that the likelihood of a systems-level implementation of
support for multiple inheritance would affect them is slight.

Python uses a simple right-hand rule system of disambiguating inheritance. The
first definition that matches the key signature will be the accepted definition.
It's up to the user to take care if that isn't what was desired. Ruby allows
definitions to rewrite themselves on the fly (not a recommended procedure, but if
you need to, it's there). Ada has one main line of inheritance, but supports
mix-ins. I'd say delegation, but the standard meaning of that term has become
muddied since MS redefined it for J++. Lisp ... Lisp is Lisp. I don't really
understand it, but it supports inheritance in several flavors. I think that Lisp
invented mix-in inheritance. You use the one that you need. Eiffel uses a
nicely structured form of multiple inheritance that detects collisions at compile
time, and provided methods, through renaming and exclusion, to resolve this in
the intended way. Eiffel doesn't try to solve the problem, it gives the
programmer the tools with which to solve the problem. Eiffel detects the
problem.


Emmanuel STAPF

unread,
Sep 17, 2000, 3:00:00 AM9/17/00
to
Have a look at

http://eiffel.com/doc/online/eiffel45/Eiffel/language/BOOK.maker.html

and especially

http://eiffel.com/doc/online/eiffel45/Eiffel/language/inheritance.maker.html

to know a little bit more about MI in Eiffel. It is far from being the
complete description of what should MI be. If you want to know more about I
recommend you to read OOSC2.

Regards,
Manu


Klaus Michelsen

unread,
Sep 17, 2000, 2:59:28 PM9/17/00
to
Eirik

Interesting comments. (Inline comments further down)

Especially the difference between C++ and Eiffel. Would you be able to very
briefly explain why Eiffel is superior to C++ in terms of MI? for example
how it solves the problems I mentioned with MI. I know this a C# newsgroup
(and that we are suddenly discussing differences between C++ and Eiffel) but
in the context I think it could add some valuable knowledge to the
discussion.

> > Interfaces solve this problem in an elegant way.
>

> With lots and lots of code duplication to go along with it.

In my experience to a certain degree yes, but in quite a few other cases, I
have also found that it has been possible to convert complex MI designs, to
a single class inheritance structure with interfaces put at carefully
selected positions without much code duplication at all, and even with a
clearer and simpler design as a result.

> So, I hope the .NET *common run-time* will include support for MI and then
> leave
> it to the language designers whether they wish to utilize this or not. I'm
> quite happy
> with C# not having MI, but the lack of MI in the common run-time sort of
> reduces
> some of Eiffel's great functionality and IMHO a VM should be at least try
to
> implement
> a super-set of the features found in the languages using its services.

I agree totally.


Cheers,

Klaus


Veli-Pekka Nousiainen

unread,
Sep 18, 2000, 1:11:24 AM9/18/00
to
"Klaus Michelsen" <dri...@ozemail.com.au> wrote in message
news:cE7x5.19463$cr3.4...@ozemail.com.au...
X

> > So, I hope the .NET *common run-time* will include support for MI and
then
> > leave
> > it to the language designers whether they wish to utilize this or not.
I'm
> > quite happy
> > with C# not having MI, but the lack of MI in the common run-time sort of
> > reduces
> > some of Eiffel's great functionality and IMHO a VM should be at least
try
> to
> > implement
> > a super-set of the features found in the languages using its services.
>
> I agree totally.
X
Ditto


Ian Joyner

unread,
Sep 18, 2000, 2:22:27 AM9/18/00
to
in article cE7x5.19463$cr3.4...@ozemail.com.au, Klaus Michelsen wrote:

> Eirik
>
> Interesting comments. (Inline comments further down)
>
> Especially the difference between C++ and Eiffel. Would you be able to very
> briefly explain why Eiffel is superior to C++ in terms of MI? for example
> how it solves the problems I mentioned with MI. I know this a C# newsgroup
> (and that we are suddenly discussing differences between C++ and Eiffel) but
> in the context I think it could add some valuable knowledge to the
> discussion.

Hi Klaus,

One thing that has been mentioned in another post is name clashes. Eiffel
easily solves this problem by having a rename clause in the inheritance
specification. With C++ you must use the scope resolution operator everytime
the clash occurs in the code, whereas Eiffel rename is a once only thing.
Yes MI has problems, but there are solutions to these problems.

There is of course heaps more that I have written up in my paper on these
issues at:

http://www.elj.com/cppcv3/

or better still in my book Objects Unencapsulated (see signature).

asa...@my-deja.com

unread,
Sep 18, 2000, 2:36:18 AM9/18/00
to
I invite someone who is a big supporter of implementation MI to give us
an example where Impl. MI is usefull and where the same thing cannot be
achieve using SI + interface MI in an effective way, or where
duplication of code would be required.

Use C++, Eiffel, or any other MI languge on your choice.

Thanks.

Anes Sadikovic


Sent via Deja.com http://www.deja.com/
Before you buy.

Joakim Johansson

unread,
Sep 18, 2000, 3:00:00 AM9/18/00
to
Hi, thats the part how makes i object orientated!!!

If you can implement multipla interfaces like in C# you don´t need to
inherit some thing from more than one class!!!

/Joakim

"Volkan Arslan" <Volkan...@gmx.net> wrote in message

news:39C36C0D...@gmx.net...

Klaus Michelsen

unread,
Sep 18, 2000, 3:00:00 AM9/18/00
to
Thanks Ian,

I'll have a good look at those sources of information.

Klaus

Eric Gunnerson

unread,
Sep 18, 2000, 3:00:00 AM9/18/00
to

"Volkan Arslan" <Volkan...@gmx.net> wrote in message
news:39C36C0D...@gmx.net...
> I would be interested, why the .NET platform (common type system of .NET
> platform and the reference language C# of .NET) don't support multiple
> inheritance. I know that C# supports multiple interface inheritance, but
> this is definitively not the same as multiple inheritance. This point is
> very interesting, as there are languages like C++ and Eiffel (and of
> course other languages) which support multiple inheritance. In case of
> Eiffel multiple inheritance is supported very elegantly. And also most
> OODBMS (like Matisse, Versant, Poet, ...) directly support multiple
> inheritance. So the question is why Microsoft has decided not to support
> multiple inheritance.
>
> I also think, that it is not too late for Microsoft to extend the common
> type system of the .NET platform (and of course C#) with multiple
> inheritance. Eiffel would be a very good reference to look how multiple
> inheritance can be integrated into an OO language. At any rate, it would
> be better to include multiple inherintance now, than later.

Two major reasons:

1) Multiple inheritance has a performance cost.
2) Whose version of multiple inheritance should be implemented? Different
languages implement things differently.

That said, it's something we've discussed, and will continue to discuss.

> The above said can also be applied to genericity, although I have heard
> rumors that Microsoft will support genericity in C#. Again the languages
> C++ and Eiffel and most OODBMS support this mechanism quite well,
> especially Eiffel with its constrained genericity.

Generics are an interesting topic, and can be really useful. It's a tough
problem; not only do you need to find a good way of implementing them, but
you need to figure out how types that are generic appear in languages
without that concept. To get these things right, you need to support generic
types in the runtime itself.

We're hoping to have generic support in a future version.


Jonathan Allen

unread,
Sep 18, 2000, 3:00:00 AM9/18/00
to

There is not really a lot of duplication going on. Check out any current VB
app that uses "inheritance". All of the methods "inherited" from the
interface are simply stubs referencing the real base class's methods. It's a
pain to type w/o an add-on, but your not duplicating any code.

Jonathan Allen

"Eirik Mangseth" <ei...@stockpoint.no> wrote in message
news:1m1x5.2040$mq2....@news1.online.no...


>
> "Klaus Michelsen" <dri...@ozemail.com.au> wrote in message

> news:KfMw5.18743$cr3.4...@ozemail.com.au...


> > I don't know the reasons for why MS is not including multiple (class)
> > inheritance (MI) , but here is my opinion about it:
> >
> > MI seems great on the surface, however it is saturated with subtleties
> which
> > makes proper design difficult, some of these are:
> >
> > 1) Two (or more) base classes may contain methods that have the same
> > signature but different implementations...which one should be chosen? or
> > they may have two identically named fields...which one should be used?
If
> > many classes are involved, things could get ugly and bugs could appear
> that
> > would be hard to trace. Interfaces solve this problem in an elegant way.
>

> With lots and lots of code duplication to go along with it.
>
> >

> > 2) Overhead is added to both the compiler and the run-time system trying
> to
> > sort out the grey areas.
>

> Most Eiffel compilers (perhaps all) don't have problems with this.
>
> Read Object-oriented Software Construction 2nd Edition for an example how
> this
> can be achieved quite elegantly. Or even better, get your hands on an
Eiffel
> compiler
> and see for yourself. After 15 years of Eiffel I'm getting a bit tired of
> seeing how
> people base their views on C++'s version of MI which is quite horrid.
> >

> > Overall I'm very happy that MS didn't allow multiple inheritance (and
hope
> > they are not going to include it), I believe multiple (class)
inheritance
> > can effectively be substituted by using a combination of single class
> > inheritance and allowing the implementation of many interfaces.
>

> Again, programming in both Eiffel and Java has shown me how badly
> Java's interface mechanism compares to the well-defined, well-controlled
> MI-mechanism that one finds in Eiffel.
>
> Sorry guys, MI is *NOT* bad, but like any other fairly advanced concept
> it requires some thought up-front, but that's a trait of good software
> engineering in
> general.
>

> So, I hope the .NET *common run-time* will include support for MI and then
> leave
> it to the language designers whether they wish to utilize this or not. I'm
> quite happy
> with C# not having MI, but the lack of MI in the common run-time sort of
> reduces
> some of Eiffel's great functionality and IMHO a VM should be at least try
to
> implement
> a super-set of the features found in the languages using its services.
>

> Eirik Mangseth
> Stockpoint Nordic AS
> Lysaker, Norway
>
> "If I can't Eiffel in heaven, I won't go"
>
> >

Jesús

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
IMHO, MI is not just a language headache. It is a design headache too. How
would you specify in UML the method a subclass should call? I think that
there is no standard notation for this. Moreover, there *are* standards to
move a design from MI to SI, and doing so you don't miss conceptual
I.( i.e. you can still, watching at your design, see that a person can be a
customer and a provider). Of course, if your design doesn't have MI, your
implementation won't do MI.

Cheers,
Jesús


Volkan Arslan escribió en mensaje <39C36EF4...@gmx.net>...

Alex Soto

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Jesús wrote:
>
> IMHO, MI is not just a language headache. It is a design headache too. How
> would you specify in UML the method a subclass should call? I think that
> there is no standard notation for this.

Please, explain why do you need to know this during design?
In any case, the argument that UML is not expressive enough to describe
MI, does not invalidate MI. Your statement is a sophism.



> Moreover, there *are* standards to
> move a design from MI to SI,

Again, this does not make SI better than MI. Another sophism.

regards,
Alex Soto

Ian Joyner

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
in article #4e8McYI...@cppssbbsa02.microsoft.com, Eric Gunnerson wrote:

> "Volkan Arslan" <Volkan...@gmx.net> wrote in message

> news:39C36C0D...@gmx.net...

>> I also think, that it is not too late for Microsoft to extend the common
>> type system of the .NET platform (and of course C#) with multiple
>> inheritance. Eiffel would be a very good reference to look how multiple
>> inheritance can be integrated into an OO language. At any rate, it would
>> be better to include multiple inherintance now, than later.
>

> Two major reasons:
>
> 1) Multiple inheritance has a performance cost.

This is just incorrect (unless you are saying everything has a performance
cost, but it is incorrect to say the MI has any performance cost over SI,
unless Microsoft thought of particularly bad ways of doing it).

> 2) Whose version of multiple inheritance should be implemented? Different

> languages implement things differently..

Neither is this a problem. Different languages have always had different
underlying concepts, but most platforms enable software written in different
languages. For example the Unisys A Series E mode architecture (which is
really the ultimate VM, with the cleanest instruction set) allows software
in languages as different as ALGOL and COBOL to run efficiently on the same
platform. Designing a VM should not be to difficult to run multiple OO
languages with different MI implementations, or even non-OO languages.

> That said, it's something we've discussed, and will continue to discuss.
>

>> The above said can also be applied to genericity, although I have heard
>> rumors that Microsoft will support genericity in C#. Again the languages
>> C++ and Eiffel and most OODBMS support this mechanism quite well,
>> especially Eiffel with its constrained genericity.
>

> Generics are an interesting topic, and can be really useful. It's a tough
> problem; not only do you need to find a good way of implementing them, but
> you need to figure out how types that are generic appear in languages
> without that concept. To get these things right, you need to support generic
> types in the runtime itself.
>
> We're hoping to have generic support in a future version.

So is Sun in Java. I wouldn't hold my breath.

Jolyon Smith

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

"Alex Soto" <as...@cawtech.com> wrote in message
news:39C75A54...@cawtech.com...

> Jesús wrote:
> >
> > IMHO, MI is not just a language headache. It is a design headache too.
How
> > would you specify in UML the method a subclass should call? I think that
> > there is no standard notation for this.
>
> Please, explain why do you need to know this during design?
> In any case, the argument that UML is not expressive enough to describe
> MI, does not invalidate MI. Your statement is a sophism.

PMFJI: You need to know this during design so that you know what it is you
have to implement. Your question suggests that you don't feel design to be
important in determining the "shape" of the implementation. Ironically,
such design is even probably even more important when MI is being
considered.

Jesus' point was not sophistry. The demonstration was made that UML, a
popular and widely regarded notation did not appear to have any support for
MI. The unstated conclusion being that if it was not considered suitable
for inclusion in UML notation, then there must be strong arguments against
it's use.

You may not agree with this conclusion or the arguments that support it, but
there was no deception.


> > Moreover, there *are* standards to
> > move a design from MI to SI,
>
> Again, this does not make SI better than MI. Another sophism.

Again, not sophistry. The point is simply made that sufficient weight is
apparently given to the opinion that SI is preferable to MI that a great
deal of work has been put into easing and standardising the transition of
legacy MI models to SI. This adds weight to the claim that SI is (at least
perceived as) preferable to MI.

I can't help but wonder if "sophism" is your "word of the week" this week.
:^)

--
Jolyon Smith
Neot Software Services Ltd.
http://www.neot.co.uk
yahoo messenger ID: jolyonsmith

Ian Joyner

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
in article eCX1fYiIAHA.299@cppssbbsa04, Jesús wrote:

> IMHO, MI is not just a language headache. It is a design headache too. How
> would you specify in UML the method a subclass should call?

In that case, as you put it (or perhaps use it), it is UML that is
deficient. One of the major problems with UML is that once things get
slightly complicated you end up with horrendous diagrams that don't help.
Neither is UML a particular help in proving correctness or even a good
design.

> I think that
> there is no standard notation for this. Moreover, there *are* standards to
> move a design from MI to SI, and doing so you don't miss conceptual


> I.( i.e. you can still, watching at your design, see that a person can be a
> customer and a provider). Of course, if your design doesn't have MI, your
> implementation won't do MI.

But that is just artificial. In many cases MI will end up with cleaner
designs and implementations. If you want to restrict yourself to SI the you
can still do so in a language with MI. However, it will soon become apparent
as to why this restriction is artificial and silly. Why not allow languages
with MI so that we can have the choice? That way, if you want to restrict
yourself to SI, you can do so, but those of us who want cleaner designs can
use MI.

> Volkan Arslan escribió en mensaje <39C36EF4...@gmx.net>...
>>
>> I would be interested, why the .NET platform (common type system of .NET
>> platform and the reference language C# of .NET) don't support multiple
>> inheritance. I know that C# supports multiple interface inheritance, but
>> this is definitively not the same as multiple inheritance. This point is
>> very interesting, as there are languages like C++ and Eiffel (and of
>> course other languages) which support multiple inheritance. In case of
>> Eiffel multiple inheritance is supported very elegantly. And also most
>> OODBMS (like Matisse, Versant, Poet, ...) directly support multiple
>> inheritance. So the question is why Microsoft has decided not to support
>> multiple inheritance.
>>

>> I also think, that it is not too late for Microsoft to extend the common
>> type system of the .NET platform (and of course C#) with multiple
>> inheritance. Eiffel would be a very good reference to look how multiple
>> inheritance can be integrated into an OO language. At any rate, it would
>> be better to include multiple inherintance now, than later.
>>

>> The above said can also be applied to genericity, although I have heard
>> rumors that Microsoft will support genericity in C#. Again the languages
>> C++ and Eiffel and most OODBMS support this mechanism quite well,
>> especially Eiffel with its constrained genericity.
>>

Ian Joyner

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
in article 8q4d51$gv2$1...@nnrp1.deja.com, asa...@my-deja.com wrote:

> I invite someone who is a big supporter of implementation MI to give us
> an example where Impl. MI is usefull and where the same thing cannot be
> achieve using SI + interface MI in an effective way, or where
> duplication of code would be required.
>
> Use C++, Eiffel, or any other MI languge on your choice.

I won't write it in any language, but anywhere where you find two or more
subclasses of an interface have the same implementation procedure. In that
case you would want to share the procedure by moving in up into the
interface, but in that case it is no longer an interface (well actually, it
is, as all classes have an interface and you don't need the artificial
distinction of interfaces as in Java or header files as in C++).

Alex Soto

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Jolyon Smith wrote:
>
> "Alex Soto" <as...@cawtech.com> wrote in message
> news:39C75A54...@cawtech.com...
> > Jesús wrote:
> > >
> > > IMHO, MI is not just a language headache. It is a design headache too.
> How
> > > would you specify in UML the method a subclass should call? I think that

> > > there is no standard notation for this.
> >
> > Please, explain why do you need to know this during design?
> > In any case, the argument that UML is not expressive enough to describe
> > MI, does not invalidate MI. Your statement is a sophism.
>
> PMFJI: You need to know this during design so that you know what it is you
> have to implement. Your question suggests that you don't feel design to be
> important in determining the "shape" of the implementation. Ironically,
> such design is even probably even more important when MI is being
> considered.
> Jesus' point was not sophistry. The demonstration was made that UML, a
> popular and widely regarded notation did not appear to have any support for
> MI. The unstated conclusion being that if it was not considered suitable
> for inclusion in UML notation, then there must be strong arguments against
> it's use.

I'm sorry, but these arguments are all sophism to me. The non inclusion
of MI in UML does not prove anything against MI. If UML does not have a
notation for specifing MI is a UML limitation, not a problem of MI.
Other notations like BON do.

>
> You may not agree with this conclusion or the arguments that support it, but
> there was no deception.
>

> > > Moreover, there *are* standards to
> > > move a design from MI to SI,
> >

> > Again, this does not make SI better than MI. Another sophism.
>
> Again, not sophistry. The point is simply made that sufficient weight is
> apparently given to the opinion that SI is preferable to MI that a great
> deal of work has been put into easing and standardising the transition of
> legacy MI models to SI. This adds weight to the claim that SI is (at least
> perceived as) preferable to MI.
>
> I can't help but wonder if "sophism" is your "word of the week" this week.
> :^)

If you want to blindly believe UML, that's your problem. But do not try
to convince others with sophisms. Yes, this my word of the week. I like
it as much as you like UML :^)


regards,
Alex Soto

Veli-Pekka Nousiainen

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
"Alex Soto" <as...@cawtech.com> wrote in message
news:39C7643E...@cawtech.com...

Xcatly ! (watching too many times the X-men DVD)
UML seems to be not only a clump of all methods and notations
together, but on the other hand it seems to be the greatest common
factor of "suitabl" languages. Only some niche languages like Eiffel
support MI well enough to be useful without being too dangerous
(bugs just creep in). But this is just MY opinion.
Let the markets lead - not the technolgoy or innovations !!!
VPN

Veli-Pekka Nousiainen

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
"Ian Joyner" <i.jo...@acm.org> wrote in message
news:B5EDACB5.4186%i.jo...@acm.org...

> in article 8q4d51$gv2$1...@nnrp1.deja.com, asa...@my-deja.com wrote:
>
> > I invite someone who is a big supporter of implementation MI to give us
> > an example where Impl. MI is usefull and where the same thing cannot be
> > achieve using SI + interface MI in an effective way, or where
> > duplication of code would be required.
> >
> > Use C++, Eiffel, or any other MI languge on your choice.
>
> I won't write it in any language, but anywhere where you find two or more
> subclasses of an interface have the same implementation procedure. In that
> case you would want to share the procedure by moving in up into the
> interface, but in that case it is no longer an interface (well actually,
it
> is, as all classes have an interface and you don't need the artificial
> distinction of interfaces as in Java or header files as in C++).

Java Inner Classes as a "solution" ?
VPN

Frank Mitchell

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

Ian Joyner wrote in message ...

>In reality, C# offers very little over Java, the best thing about .NET is
>that it allows multiple languages so the shortcomings of C# can be stepped
>around, whereas with Java this is more difficult.


I've heard this claim before. Can anyone point to particular language
features that make the C# "virtual machine" -- let's call it what it is --
an easier target for other languages than JVM bytecodes. (The only thing I
can think of is its support for COM pointers and pointers to blocks of raw
memory ... and the latter feature might open up big security holes for the
sake of resembling C/C++.)

Thanks.

Frank

Frank Mitchell

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

Ian Joyner wrote in message ...
>in article #4e8McYI...@cppssbbsa02.microsoft.com, Eric Gunnerson wrote:
>
>> "Volkan Arslan" <Volkan...@gmx.net> wrote in message
>> news:39C36C0D...@gmx.net...
>
>> 1) Multiple inheritance has a performance cost.
>
>This is just incorrect (unless you are saying everything has a performance
>cost, but it is incorrect to say the MI has any performance cost over SI,
>unless Microsoft thought of particularly bad ways of doing it).


MI has no performance cost in a language with global analysis (e.g. Eiffel,
Dylan), but what about languages which can link in new classes at runtime,
like Java and C#? Most of the performance hit will occur at link time, as
the runtime rebuilds its class tables to accomodate the new class. But,
unless there's a well-known clever algorithm for extending class tables
without halting all threads for a noticeable length of time, an implementor
in the real world will probably choose techniques less efficient than a SI
array index.

Frank


WildHeart'2k

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

> I've heard this claim before. Can anyone point to particular language
> features that make the C# "virtual machine" -- let's call it what it is --
> an easier target for other languages than JVM bytecodes.

Any language (like Scheme or Haskell) where tail-recursion must be
implemented efficiently according to the specs of the language and re-using
the stack-frame. The authors of all the Scheme to Java compilers I've seen
admit that the JVM limitations forced them to implement tail-recursion in a
very inefficient way, completely destroying the semantic of that particular
part of the language (check the reports on Kawa for instance).
The CLR has a native "tail call" opcode so it does not suffer from this
limitation.
--
WildHeart'2k

Veli-Pekka Nousiainen

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
OK !

ThanX Frank !

"Frank Mitchell" <fra...@bayarea.net> wrote in message
news:8q7sbo$mgn$1...@localhost.localdomain...

Charles Hixson

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Veli-Pekka Nousiainen wrote:

> "Ian Joyner" <i.jo...@acm.org> wrote in message
> news:B5EDACB5.4186%i.jo...@acm.org...
> > in article 8q4d51$gv2$1...@nnrp1.deja.com, asa...@my-deja.com wrote:
> >

> > > I invite someone who is a big supporter of implementation MI to give us
> > > an example where Impl. MI is usefull and where the same thing cannot be
> > > achieve using SI + interface MI in an effective way, or where
> > > duplication of code would be required.
> > >
> > > Use C++, Eiffel, or any other MI languge on your choice.
> >

> > I won't write it in any language, but anywhere where you find two or more
> > subclasses of an interface have the same implementation procedure. In that
> > case you would want to share the procedure by moving in up into the
> > interface, but in that case it is no longer an interface (well actually,
> it
> > is, as all classes have an interface and you don't need the artificial
> > distinction of interfaces as in Java or header files as in C++).
>
> Java Inner Classes as a "solution" ?
> VPN
> > --
> > Ian Joyner
> > i.jo...@acm.org http://homepages.tig.com.au/~ijoyner/

> ...

Inner classes are an anti-solution. They pretty much guarantee that the code
cannot be shared (isn't that their purpose?). I'm glad that you put "solution"
in quotes.

-- (c) Charles Hixson
-- Addition of advertisements or hyperlinks to products specifically prohibited


charleshixsn.vcf

Charles Hixson

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Sophism is, perhaps, the wrong word. They do not, however, rank as convincing
arguments. To the extent that I feel the author was aware of ignoring factors,
I consider him disingenuous. I really don't know or care at which point along
that spectrum he is positioned. The argument is unsound. Perhaps there is a
valid one. I don't know. But that one isn't it.

Personally I was most impressed by the claim (Frank Mitchell, Re: Multiple
inheritance in..., 09/19/2000, 07:22:57 - 0700) that languages that can load
routines at run time need single inheritance to achieve reasonable efficiency.
I can't validate the truth of that, but nobody has challenged it in the thread
as of now.

Jolyon Smith wrote:

> "Alex Soto" <as...@cawtech.com> wrote in message
> news:39C75A54...@cawtech.com...
> > Jesús wrote:
> > >
> > > IMHO, MI is not just a language headache. It is a design headache too.
> How
> > > would you specify in UML the method a subclass should call? I think that
> > > there is no standard notation for this.
> >
> > Please, explain why do you need to know this during design?
> > In any case, the argument that UML is not expressive enough to describe
> > MI, does not invalidate MI. Your statement is a sophism.
>
> PMFJI: You need to know this during design so that you know what it is you
> have to implement. Your question suggests that you don't feel design to be
> important in determining the "shape" of the implementation. Ironically,
> such design is even probably even more important when MI is being
> considered.
>
> Jesus' point was not sophistry. The demonstration was made that UML, a
> popular and widely regarded notation did not appear to have any support for
> MI. The unstated conclusion being that if it was not considered suitable
> for inclusion in UML notation, then there must be strong arguments against
> it's use.
>

> You may not agree with this conclusion or the arguments that support it, but
> there was no deception.
>
> > > Moreover, there *are* standards to
> > > move a design from MI to SI,
> >
> > Again, this does not make SI better than MI. Another sophism.
>
> Again, not sophistry. The point is simply made that sufficient weight is
> apparently given to the opinion that SI is preferable to MI that a great
> deal of work has been put into easing and standardising the transition of
> legacy MI models to SI. This adds weight to the claim that SI is (at least
> perceived as) preferable to MI.
>
> I can't help but wonder if "sophism" is your "word of the week" this week.
> :^)
>

> --
> Jolyon Smith
> Neot Software Services Ltd.
> http://www.neot.co.uk
> yahoo messenger ID: jolyonsmith

-- (c) Charles Hixson

charleshixsn.vcf

Jolyon Smith

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

"Veli-Pekka Nousiainen" <vp.nou...@lapinlahden-teknologiakeskus.fi>
wrote in message news:GNJx5.210$s17....@read2.inet.fi...

> UML seems to be not only a clump of all methods and notations
> together,

Well it is the "unified" method so you would sort of expect that, no? :-)

> Let the markets lead - not the technolgoy or innovations !!!

Which is what I was driving at when "defending" Jesus' statement. UML
represents the formed conclusion of a body of opinion. Furthermore, it is a
conclusion which, if the take up of UML is to be taken as anything like
representative, has largely gotten the thumbs up from the IT industry.

If UML excludes support for MI there is a case to be argued that this very
fact demonstrates that MI has been ruled at least unnecessary by that body
of opinion.

I myself am not a big fan of UML. Neither am I particularly zealous about
the use or non-use of MI, although I am of the school of thought that views
it as largely unnecessary. I do acknowledge that it offers a more elegant
solution in some cases than SI + interfaces (and have used this fact in the
past to great effect, though I say so myself). But I also believe that
there is nothing that MI can do that SI + interfaces can't also achieve.

And based on my own experience, I prefer SI + I's over MI. It somehow
"feels" more "right". But that's just my experience.

Veli-Pekka Nousiainen

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
"Jolyon Smith" <jsm...@neot.co.uk> wrote in message
news:eQJ9dEl...@cppssbbsa02.microsoft.com...

>
> "Veli-Pekka Nousiainen" <vp.nou...@lapinlahden-teknologiakeskus.fi>
> wrote in message news:GNJx5.210$s17....@read2.inet.fi...
X

> If UML excludes support for MI there is a case to be argued that this very
> fact demonstrates that MI has been ruled at least unnecessary by that body
> of opinion.

No - no - no ! Not unnecessary, but too complicated for some languages
and UML is targeted to support SI implementations, too !!!

Veli-Pekka
Disclaimer of the day:
"Any opinions of mine
are a direct order from my Company
to you all - follow it !!"

Jolyon Smith

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

"Alex Soto" <as...@cawtech.com> wrote in message
news:39C7643E...@cawtech.com...

> I'm sorry, but these arguments are all sophism to me.

Then I suggest you look it up. :^)

> The non inclusion of MI in UML does not prove anything against MI.

Since this is a discussion based largely on opinion there is no "proof"
required or provided. But when defending an opinion it is perfectly valid
to point to the opinion of others as a way of adding weight to that opinion.

UML is a recognised and widely acknowledged notation. It is reasonable
therefore to suggest that those who give the "thumbs up" to UML largely
"agree" with the assumptions that UML forces on them. And that includes
(apparently) the view that MI is not necessary.


> Other notations like BON do.

So what? :^)


> If you want to blindly believe UML, that's your problem. But do not try
> to convince others with sophisms. Yes, this my word of the week. I like
> it as much as you like UML :^)

Unfortunately however, it would seem that you understand it's meaning a
little less well. I point out again that no-one has used UML to try and
deceive or confuse anyone or anything. UML has simply been offered as
evidence of wider support for a particular POV.

IMHO that's not sophistry, that's reasoned debate.

Alex Soto

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Jolyon Smith wrote:
>
> "Alex Soto" <as...@cawtech.com> wrote in message
> news:39C7643E...@cawtech.com...
>
> > I'm sorry, but these arguments are all sophism to me.
>
> Then I suggest you look it up. :^)
>
> > The non inclusion of MI in UML does not prove anything against MI.
>
> Since this is a discussion based largely on opinion there is no "proof"
> required or provided. But when defending an opinion it is perfectly valid
> to point to the opinion of others as a way of adding weight to that opinion.
>
> UML is a recognised and widely acknowledged notation. It is reasonable
> therefore to suggest that those who give the "thumbs up" to UML largely
> "agree" with the assumptions that UML forces on them. And that includes
> (apparently) the view that MI is not necessary.
>
> > Other notations like BON do.
>
> So what? :^)
>
> > If you want to blindly believe UML, that's your problem. But do not try
> > to convince others with sophisms. Yes, this my word of the week. I like
> > it as much as you like UML :^)
>
> Unfortunately however, it would seem that you understand it's meaning a
> little less well. I point out again that no-one has used UML to try and
> deceive or confuse anyone or anything.

That's exactly what I read from you and Jesus. Impliying that MI is
unnecessary from the fact that UML does not support MI is an invalid
argument used to deceive people about the effectiveness of MI. Better
go and find real arguments to back your statements. Picking on my
choice of words won't help your cause.

regards,
Alex Soto

Bertie Wooster

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

"Charles Hixson" <charle...@earthlink.net> wrote...

> Sophism is, perhaps, the wrong word.

What do you mean, "perhaps"? Of course it's the wrong word. It should be
"sophistry".

Any fule no that.

Bertie

Jonathan Allen

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

JVM doesn't support Delegates, or what we VB programmers know as events.
Instead, they all the to be wrapped in event classes.

In fact, that was a big part of the Sun vs. MS battle. MS said "I works
better this way, just look at VB and C++" while Sun was saying "That's not
Java! You can't go around changing stuff". Both were correct, but it was
Sun's ball and they went home. Thus MS made their own.

Jonathan Allen

"Frank Mitchell" <fra...@bayarea.net> wrote in message

news:8q7rid$mfl$1...@localhost.localdomain...


>
> I've heard this claim before. Can anyone point to particular language
> features that make the C# "virtual machine" -- let's call it what it is --

Gunnar Skogsholm

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

Multiple inheritance is usually bad design. It usually violates true IS-A
relationships or it places things at an incorrect level of abstraction.
For example, Man IS-A Person, Man IS-A Programmer. This makes Programmer
as essential to attributes of Man as Person is. This is incorrect
abstraction. It's more logical to design Man IS-A Person, Man HAS-A Skill
of type Programming.

A good designer can always design incorrect MI as proper SI.

"Alex Soto" <as...@cawtech.com> wrote in message

news:39C75A54...@cawtech.com...
> Jesús wrote:
> >
> > IMHO, MI is not just a language headache. It is a design headache too.
How
> > would you specify in UML the method a subclass should call? I think that
> > there is no standard notation for this.
>
> Please, explain why do you need to know this during design?
> In any case, the argument that UML is not expressive enough to describe
> MI, does not invalidate MI. Your statement is a sophism.
>

> > Moreover, there *are* standards to
> > move a design from MI to SI,
>
> Again, this does not make SI better than MI. Another sophism.
>

> regards,
> Alex Soto


>
>
>
> >and doing so you don't miss conceptual
> > I.( i.e. you can still, watching at your design, see that a person can
be a
> > customer and a provider). Of course, if your design doesn't have MI,
your
> > implementation won't do MI.
> >

> > Cheers,
> > Jesús

Ken Alverson

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

"Ian Joyner" <i.jo...@acm.org> wrote in message
news:B5EDACB5.4186%i.jo...@acm.org...
> in article 8q4d51$gv2$1...@nnrp1.deja.com, asa...@my-deja.com wrote:
>
> I won't write it in any language, but anywhere where you find two or more
> subclasses of an interface have the same implementation procedure. In that
> case you would want to share the procedure by moving in up into the
> interface, but in that case it is no longer an interface (well actually,
it
> is, as all classes have an interface and you don't need the artificial
> distinction of interfaces as in Java or header files as in C++).

Implementation classes give much of the same basic functionality of MI, for
example, take the possibly contrived example of a RandomNumberStream. A
stream that spits out random numbers. You could look at it in two ways:

The MI way:
RandomNumberStream is-a Stream
RandomNumberStream is-a RandomNumberGenerator
class RandomNumberStream : public Stream, private RandomNumberGenerator
{...};

or the SI way:
RandomNumberStream is-a Stream
RandomNumberStream has-a RandomNumberGenerator
class RandomNumberStream : public Stream {
RandomNumberGenerator rng;
...
};

For most stuff, it's very little difference code-wise.

Ken

Jonathan Allen

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Pay attention. The previous post asked what made C#'s virtual machine easier
to target than Java's.

Jonathan Allen

"Neil Hodgson" <ne...@scintilla.org> wrote in message
news:#o3MCspIAHA.286@cppssbbsa04...
> Jonathan Allen:


> > JVM doesn't support Delegates, or what we VB programmers know as events.
> > Instead, they all the to be wrapped in event classes.
>

> Microsoft's implementation of delegates generates Java byte code that
> will run on any JVM. The dispute here was over the change to the Java
> language rather than to the VM.
>
> http://www.microsoft.com/presspass/trial/mswitness/muglia/muglia_pt2.asp
>
> Neil
>
>
>

Peter Drayton

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

Here's a few:

1. The .NET stack is typed, and the opcodes are smart enough to 'do the
right thing' w.r.t the stack. For an example, look at the numerous JVM
bytecodes to add 2 numbers together, vs. the simple add opcode in .NET.

2. The .NET stack treats all values as atomic, ie. you don't have to do
things like use pop2 or dup2 if the top of the stack holds a double.

3. The CLR supports unsigned data types.

4. The CLR supports .tailcall for more efficient implementation of recursive
languages like Scheme.

I'm sure there's more, but I'm still learning about the JVM. The more I
read, the more I think that the CLR architects did a better job. However,
this isn't too suprising given the presence of 20/20 hindsight.

--Peter
http://www.razorsoft.net

"Frank Mitchell" <fra...@bayarea.net> wrote in message
news:8q7rid$mfl$1...@localhost.localdomain...
>

> Ian Joyner wrote in message ...

> >In reality, C# offers very little over Java, the best thing about .NET is
> >that it allows multiple languages so the shortcomings of C# can be
stepped
> >around, whereas with Java this is more difficult.
>
>

Chris Smith

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to
Peter Drayton <pe...@razorsoft.com> wrote in message
news:OOAoxIrIAHA.195@cppssbbsa05...

> 1. The .NET stack is typed, and the opcodes are smart enough to 'do the
> right thing' w.r.t the stack. For an example, look at the numerous JVM
> bytecodes to add 2 numbers together, vs. the simple add opcode in .NET.
>
> 2. The .NET stack treats all values as atomic, ie. you don't have to do
> things like use pop2 or dup2 if the top of the stack holds a double.

[...]

> I'm sure there's more, but I'm still learning about the JVM. The more I
> read, the more I think that the CLR architects did a better job. However,
> this isn't too suprising given the presence of 20/20 hindsight.

Umm, so long as you realize that those two points only move around some of
the translation rather than eliminating it. A simple declaration that "you
don't need dup2" doesn't mean that the implementation... duplicating two
machine words of data, isn't required. It means that the operation that
used to be a compile time check is now a run-time check. Same with typed
operations. The trade-off is that the bytecode (that is, the part that
isn't supposed to be human readable) is simpler and easier for humans to
read, but executes slower.

Java does need some way to guarantee tail recursion optimizations, and
unsigned types would make sense too.

Chris Smith


Peter Drayton

unread,
Sep 19, 2000, 3:00:00 AM9/19/00
to

Sure, I realize that. It's just easier to read & write (by hand)...

--Peter
http://www.razorsoft.net

"Chris Smith" <cds...@twu.net> wrote in message
news:8q9c4b$i6n$0...@dosa.alt.net...

Karsten Walter

unread,
Sep 19, 2000, 8:09:53 PM9/19/00
to

First, in fact I am no big supporter of MI. But as every possible
implementation of OO it has some advantages.

Some time ago, for test purposes, I built a COM server which implemented
some of the standard C++ library sets (vector, stack, queue, etc.).
Ok, C++ genericity has some severe drawbacks (implemetation in header
files...) and C++ MI also.
But using MI (ATL for the COM purposes) you can get a very elegant way to
implement common functionality in several base classes which can be
inherited by the exposed COM classes (think about the common functionality
of vector, stack, queue, deque, list and their iterators).

By using SI I had to implement the methods of every COM interface (which is
in fact for C++ a pure virtual class) in every implementation class. By
using MI I could provide every common implementation in a seperate base
class in this way that the inheriting class gets all the implementations of
all interface methods it needs without implementing all of these methods
itself.

This is a very imperative, not to say academic, example, I know, but...
the discussion about the "musts" of implementations of OO principles also
is. When we talk about the necessity of MI think about this principle of OO
design: composition is better than inheritance. This leads to the "white
box" - "Black box" problem. White box: show how to use your component (in
fact an interface), black box: hide the implementation. Inheritance (both SI
and MI) can break this principle when not used very carefully.

Hope we can get Deep Thought to tell us the answer about all the OO stuff!
Karsten

<asa...@my-deja.com> wrote in message news:8q4d51$gv2$1...@nnrp1.deja.com...


> I invite someone who is a big supporter of implementation MI to give us
> an example where Impl. MI is usefull and where the same thing cannot be
> achieve using SI + interface MI in an effective way, or where
> duplication of code would be required.
>
> Use C++, Eiffel, or any other MI languge on your choice.
>

> Thanks.
>
> Anes Sadikovic
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Ian Joyner

unread,
Sep 19, 2000, 10:13:32 PM9/19/00
to
in article #n1D0ajI...@cppssbbsa02.microsoft.com, Jolyon Smith wrote:

>
> "Alex Soto" <as...@cawtech.com> wrote in message
> news:39C75A54...@cawtech.com...
>> Jesús wrote:
>>>
>>> IMHO, MI is not just a language headache. It is a design headache too.
> How
>>> would you specify in UML the method a subclass should call? I think that
>>> there is no standard notation for this.
>>
>> Please, explain why do you need to know this during design?
>> In any case, the argument that UML is not expressive enough to describe
>> MI, does not invalidate MI. Your statement is a sophism.
>

> Jesus' point was not sophistry. The demonstration was made that UML, a
> popular and widely regarded notation did not appear to have any support for
> MI. The unstated conclusion being that if it was not considered suitable
> for inclusion in UML notation, then there must be strong arguments against
> it's use.

Hang on, I don't believe the claim that UML does not support MI is correct
anyway. If it is true, then UML is even more useless than I thought.
However, it could probably be argued over since even the UML and modeling
experts I know say UML is so badly defined that no one really agrees on the
meaning of things and the same diagram can mean different things depending
on how you interpret the basic definitions.

I again make the point that if you don't like MI (perhaps because you have
seen it in C++), let us have the language with MI, and you can restrict
yourself to using it with SI, that way we will all be happy.

Eiffel for Macintosh