[Prev][Next][Index][Thread]
Re: Multiple dispatch / multimethods??
Hi Gail,
Many thanks for your reply.
"Gail Zacharias" <nospam@nospam.com> wrote in message
3b5b8384.130280565@news.erols.com">news:3b5b8384.130280565@news.erols.com...
> 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.
Sorry, but I don't understand. I wish to compare not "overriding" (i.e.
inheritance) but "overloading". For the sake of the argument we might even
define one big (huge!) GenericFunction class containing a (separate) set of
overloaded static methods for each generic function we wish to implement.
Ignoring the issue of compile-time v. run-time resolution, how closely does
the signature-based mechanism the Java compiler uses to select the
appropriate method to "dispatch to" resemble the "multiple-dispatch"
mechanism employed by the Dylan compiler/runtime's generic function
implementation?
Moreover, would structuring one's Java classes along the above lines offer
any potential benefits? If not, are there other class structuring
conventions that might be used in Java to proffer benefits such as those
promised by Dylan's multimethods?
many tias,
gary
Follow-Ups:
References: