Another question, guys.

In his book _Object-Oriented Perl_, Damian Conway discusses
what he calls "interface polymorphism" (as distinguished
from inheritance polymorphism). Basically as long as two
objects both implement the method needed at the moment, no
ancestor relationship need exist between the objects.

He also says that the language needs a mechanism for
determining whether a given method actually exists.

I immediately thought of Ruby's "mix-in" capability (and
the method_missing method). I think this is certainly an
example of what Conway was talking about.

However, I also started thinking of Java's interfaces and
what Arnold & Gosling call "interface inheritance." At
first I thought it was the same thing; but then I realized
that in a sense they are opposites. Java wants the class to
implement the functionality of the specified methods; it
may or may not provide its own. Ruby, on the other hand,
uses mix-ins as a way of importing functionality; there are
typically no "abstract" or unimplemented methods in a module
that is mixed in.

I was also thinking at first that Java's interface inheritance
was a way of avoiding MI but keeping some of its advantages.
But then I realized that there can be name clashes in interfaces
also. So are they really avoiding MI at all?

They claim that the real problem of MI is inheriting multiple
*implementations*, not interfaces. I will have to think about
that.

For that matter, I am not sure how Ruby handles name clashes --
i.e., names defined in more than one included module. I suppose
you simply use the fully qualified name?

Comments??

Hal


--
Hal Fulton


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