[Prev][Next][Index][Thread]
Re: Multiple dispatch / multimethods??
On Sat, 21 Jul 2001 21:36:01 +1000, "Gary Stephenson"
<garys@ihug.com.au> wrote:
>I am intrigued by the notion of multimethods, and would appreciate some
>feedback on the following notion:
>
>Assume one was to adopt a convention in one's Java programs to have two
>distinct class hierarchies. The first type of class - ( call it a
>"DylanClass" ) would, by convention, only ever contain instance variables,
>plus appropriate setter/getter methods. The second class would be an
>abstract class (call it a "GenericFunctionClass" ) serving as a sort of
>prototypical generic function. Each actual "generic function" would then be
>a descendant of the "GenericFunctionClass", containing nothing but a bunch
>of overloaded constructor methods.
>
>How close would these GenericFuntion instance then be to Generic Functions a
>la Dylan? What would be the salient differences? Could/would such an
>approach be of any benefit to one's Java programs?
Unfortunately, this doesn't get you the benefit of multimethods. There
are two aspects to multimethods which are intimately tied together.
One is the organizational one -- methods do not live inside classes,
they live inside generic functions, as you describe. But the point of
multimethods is that all the arguments participate in method
selection. In Java, you can only do method selection (overriding) on
the class containing the method. For all the method arguments, the
actual class of the argument is ignored.
So just creating a "GenericFunction" Java object and with a bunch of
Java methods won't do do simulate a generic function. You also have
to add code to do the dispatch by hand, different code for each
GenericFunction.
Gail Zacharias
gz -at- functionalobjects.com
Follow-Ups:
References: