Why isn't multiple inheritance very useful?

[Alan Krueger]

Why do people asked loaded rhetorical questions in the most innocent
manner possible?

Particularly about religious issues.[1] This looks to be a well-formed
troll (intentional or otherwise) given the responses it's generating.


[1] http://www.catb.org/~esr/jargon/html/R/religious-issues.html

 

[Andreas Huber]

Andreas, there is a lot of truth in your statements. But think about
this.
Java does not have enumeration type. It turn out that one actually
needs it. So, in Java one turns a class into a global namespace by
declaring everything in it as static. That simulates enumeration.

I believe it was a mistake to not give Java an enum type. In terms of
implementation, additional compiler complexity and necessary performance
trade-offs an enum is extermely cheap.

However, just because one has MI available, it does not mean that one
should use it where it makes no sense. But when it is needed,
simulating it is awkward, just as simulating enumeration is.

I agree, but as I pointed out my last message: Full MI has its price,
especially in a GCed language. I think it speaks volumes that none of
the modern GCed languages support full MI. Yes, this is sometimes
inconvenient and rarely just downright annoying, but the benefit of this
is that garbage collectors perform much better. The important part is
that GC is faster for *everyone* and *always* while full MI is a true
advantage only rarely (in a single-rooted inheritance tree). It's a
trade-off.

Regards,

 

[Ioannis Vranos]

Whether true or not, it certainly is, or at least was, a widely held belief,
that multiple inheritance doesn't turn out to be of much practical use.
Perhaps in the couple years since I last heard that (or read it) "modern c++
design" has evolved to include widespread use of multiple inheritance. My
question would then become "why did it take so long for multiple inheritance
to catch on".

Unless you want to deny that multiple inheritance was ever considered to be
a slight disappointment regarding its practical use.

Multiple inheritance is in widely use. One example of widely used
multiple inheritance is the use of interfaces.

 

[Ioannis Vranos]

I am not sure whether you guys are joking, or these are serious
concerns. Multiple inheritance is not possible for virtual machines
with the technology underlying Smalltalk, Java and C#. It is easy to
see who spreads the word that multiple inheritance is complicated. The
question is, who is it complicated for? The designer of the language or
the engineer?

Java and C# support multiple inheritance from interfaces only. They do
not support complete multiple inheritance but they do support this subset.


And more precisely (as you mentioned) it is not supported by the
underlying VM. So .NET does not support complete multiple inheritance,
and it is not a C# issue. Complete multiple inheritance is not available
to C++ too, when writing .NET managed code.

 

[Pete Becker]

As for garbage collection, it is not easy to just say a few things
about pointers and make much sense. However, Java garbage collection is
a consequence of yet another difficult issue. Have you noticed that all
interpreted languages, and those running on VM do not have pointers? It
is a lot easier to do garbage collection, and then make a big deal
about it.

Java does have pointers, but they call them references.

The use of pointers is extremely difficult.

The use of pointers is easy. It's pointer arithmetic that can get
tricky, and makes garbage collection harder. But there's nothing
insurmountable there.

 

[Zorro]

I apologize if you found the introduction of an evolution religiously
offensive. I am actually apologizing although it may be possible to
interpret statements in different ways.
On a search I came accross this topic. I could not resist the
temptation to rectify the effects of a poison that is being spread with
negative propaganda. The question got my attention because I hear it
from every Java programmer, and when I ask them if they have ever used
multiple-inheritance, or they even know what is bad about MI, the
answer is definitely negative.
An evolution will take place, trolling or otherwise. It is only worth
your time to try to contribute. For instance, what do you find wrong
with the responses? Can you help other readers avoid getting confused?
I thought the purpose of these discussions is that someone posts a
question for clarification. Those who are interested in the same topic,
share their views. Am I wrong?

Regards,
Z.

 

[Owen Jacobson]

I believe it was a mistake to not give Java an enum type. In terms of
implementation, additional compiler complexity and necessary performance
trade-offs an enum is extermely cheap.

So did the Java community. Java now has an enum type which is a
fully-featured class, just like any other -- but with fixed, pre-created
instances.

 

[Stewart Gordon]

[ ... ]

The same applies to GC languages that were designed to be complied
into native code. D is one; can anyone think of others?

Oh, let's see: ML/SML, Algol68, Modula III, Eiffel (after "freezing"),
BASIC (GC only on strings),

<snip>

How many BASIC dialects were made to be compiled rather than
interpreted? And anyway, whether it uses GC on strings is surely
implementation dependent. Two options come to mind:
- use GC, copy on write (maybe this is one instance in which reference
counting would be the more efficient option)
- copy on assignment, deallocate when it goes out of scope (in some
primitive BASICs that don't have procedures, this would mean deallocate
never, or perhaps only when assigned the value "")

Stewart.

 

[Jerry Coffin]

Stewart Gordon wrote:

[ ... ]

How many BASIC dialects were made to be compiled rather than
interpreted?

The question was not dialects, but language. The language was
originally designed to be compiled to native code, and for that matter
the first implementations DID compile to native code.

And anyway, whether it uses GC on strings is surely
implementation dependent.

It was _designed_ to use GC. You can argue that it might be possible to
implement it in other ways if you want, but then the same is true of
other things as well. There definitely HAS been at least one Lisp
interpreter that didn't use GC, but that doesn't change the original
design or intent.

Two options come to mind:
- use GC, copy on write (maybe this is one instance in which reference
counting would be the more efficient option)

Reference counting isn't an alternative to reference counting --
rather, it's a technique that _supports_ reference counting.

- copy on assignment, deallocate when it goes out of scope (in some
primitive BASICs that don't have procedures, this would mean deallocate
never, or perhaps only when assigned the value "")

Given the memory constraints at the time (remember, BASIC has been
around since 1964) this simply wasn't a realistic option.

The bottom line: BASIC strings were designed with GC in mind, and
essentially virtually every BASIC implementation ever has used exactly
that. Theoretically there may be other options, but none of this
changes the intent of the original design, nor the fact that the
majority of BASIC implementations _have_ used GC. It is true that there
have been quite a few
BASIC interpreters, but it's also true that it was designed to be
compiled, and many implementations have done exactly that.

 

[Stewart Gordon]

Stewart Gordon wrote:

Reference counting isn't an alternative to reference counting --

Whoever suggested that it should be?

Or is that a typo for "Reference counting isn't an alternative to
garbage collection" or vice versa? Again, I didn't mean to imply that
it was. Simply that reference counting might be the optimal method
(over mark-sweep or whatever) of GC in this instance. As the copying
can be skipped when the count is 1, saving some of the reallocation
overhead during string manipulations.

The bottom line: BASIC strings were designed with GC in mind, and
essentially virtually every BASIC implementation ever has used
exactly that. Theoretically there may be other options, but none of
this changes the intent of the original design, nor the fact that the
majority of BASIC implementations _have_ used GC. It is true that
there have been quite a few BASIC interpreters, but it's also true
that it was designed to be compiled, and many implementations have
done exactly that.

I see. But now that some BASICs have dynamic arrays and even partial
OOP support, I guess GC in BASIC is taken to a new level.

Stewart.

 

[Jerry Coffin]

Stewart Gordon wrote:

[ ... ]

Or is that a typo for "Reference counting isn't an alternative to
garbage collection" or vice versa?

Yes, exactly.

Again, I didn't mean to imply that
it was. Simply that reference counting might be the optimal method
(over mark-sweep or whatever) of GC in this instance. As the copying

can be skipped when the count is 1, saving some of the reallocation
overhead during string manipulations.

I'd tend to agree -- the primary shortcoming of reference counting is
its inability to deal with cycles, and I'm reasonable certain BASIC
woudldn't let you create a cycle in a string to start with (modulo bugs
and such, of course).

[ ... ]

I see. But now that some BASICs have dynamic arrays and even partial

OOP support, I guess GC in BASIC is taken to a new level.

Probably. I haven't looked recently to know what sort of dynamic arrays
you're talking about, but many versions have been able to resize
(redim) arrays for quite a while -- but it was done explicitly, so it
could be implemented roughly like realloc is in C.