[Prev][Next][Index][Thread]
Re: Multiple dispatch / multimethods??
Hi. The difference is the following. Consider the following class hierarchy
Foo2 subclasses Foo
Bar just another bare class
and the methods
do(Foo a,Bar b)
do(Foo2 a,Bar b)
overloading method resolution takes place at compilation. It uses the
stattically known
types of the arguments to choose among the possibilities
with just overloading
Foo a = ...
Bar b = ...
do(a,b)
will always call do(Foo,Bar) indipendently of the actual concrete classes of
a and b at runtime.
OTOH under multi-method dispatch decisions are taken at runtime based on the
actual classes of all arguments, like for single dynamic dispatch for
methods in Java:
do(a,b)
under multi-dispatch will possibly call do(Foo2,Bar) if a is truly a Foo2
object at runtime.
=> You cannot use overloading to mimic multi-dispatch :(
regards, Samuele Pedroni.
"Gary Stephenson" <garys@ihug.com.au> schrieb im Newsbeitrag
9jg1tl$12s$1@bugstomper.ihug.com.au">news:9jg1tl$12s$1@bugstomper.ihug.com.au...
> 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
>
>
>
>
References: