[Prev][Next][Index][Thread]

RE: MI: why?

At times I wonder if there isn't a need for several different kinds of
programming languages.  Some for advanced programmers, others for less
advanced programmers.  Clearly when MI is used properly it is very useful,
but it can get a less experienced programmer in to trouble.  The problem is:

1.  Most class hierarchies created by an average programmer are flat.  That
is inheritance is not used all that heavily, and

2.  It is often non-trivial for a programmer to understand all of the
consequences of the mixture of the behaviors of several super classes.

Java tried to solve this problem with interfaces.  Several unrelated classes
could share the same class interface (or API).  If the interface is used
consistently all classes that share an interface have a set of methods that
can be used in the same way.  For example if class A, B, and C all implement
interface I with a method f, then we can write:

	g(I anI)
	{
		anI.f();
	}

And pass any instance of A, B or C to the method g.  The disadvantage of
this approach that you can end up duplicating code implementing interface
methods in the various classes.  (With MI you can re-use the code as long as
there is no harmful interactions with other super classes.)

Smalltalk avoids the problem altogether by allowing an object of any class
to be passed to a method, stored in a variable, etc.  Smalltalk programmers
routinely think in terms of shared interfaces even if those do not have to
be declared.

The easy way out of the duplicated code problem is to implement certain
operations by delegation.  That is declare and create an instance of a class
that implements the interface's methods in a general way.  All methods that
implement the interface can pass the call on to that object.

I regularly code in Java (not my first choice), but I admit that delegation
does the job reasonably well in most situations.  There are always
trade-offs in the design of any programming language.  I do not agree that
the designers of Java made a serious mistake by not including MI.  They were
designing the language for an audience that still has serious trouble with
single inheritance, never mind multiple.

> -----Original Message-----
> From: Scott Ribe [mailto:sribe@miqs.com]
> Sent: Wednesday, January 12, 2000 12:00 PM
> To: info-dylan@ai.mit.edu
> Subject: Re: MI: why?
>
>
> Actually, I somewhat understated the case against SI by forgetting to
> elaborate how the effects build. You don't wind up just shoving a small
> utility class to a certain level way up the hierarchy so that it can be
> inherited across otherwise unrelated classes. You often wind up with
> several such classes shoved up to the same level. So for instance as you
> "better" factor the larger classes at the leaves, you wind up factoring
> common sets of functionality into classes A, B and C. Now there may be
> no class that needs all 3, but to get them to where they can be shared
> as needed they must be moved up to same level, but of course they don't
> have any actual relationship to each other. So now you have the
> following equivalent choices for that piece of the hierarchy:
>
> A->B->C
> A->C->B
> B->A->C
> B->C->A
> C->A->B
> C->B->A
>
> So with SI not only do you have problems locating and placing
> functionality in the hierarchy, you have the problem that substantial
> portions of the hierarchy may in fact be meaningless and you must figure
> out whether B inherits from A in order to extend A or whether A is
> actually totally unrelated to B and is just being inherited so that it
> can be passed on down through the hierarchy to some other class that
> really needs it.
>
> SI forces into the hierarchy many relationships that have no real
> meaning but are mere artifacts of the limitations of SI, thus adding
> much confusion about what the "real" relationships are.
>
Follow-Ups: References: