[Prev][Next][Index][Thread]
Re: Multiple dispatch / multimethods??
On Sunday, July 22, 2001, at 10:30 PM, Gary Stephenson wrote:
> Sorry, but I don't understand. I wish to compare not "overriding" (i.e.
> inheritance) but "overloading".
I think the reason you're having a problem here is that generic
functions subsume both overriding and overloading. That is, you can use
the generic function dispatch mechanism to do both - define a method
that has the same name but functions on totally different sets of
classes (overloading), - or define a method that has exactly the same
parameters as another method, except that one (or more) of the
parameters of the second method are a subclass (or subclasses) of the
parameters of the existing method.
Maybe this helps: Generic functions are like overloading where every
single parameter is considered when doing dispatch, and subclasses of
the parameters will "match" their superclass(es) for the purposes of
dispatch. This dispatch can be dynamic (runtime) or not, at the
programmers choice in Dylan.
> 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.
We might also implement a whole Dylan compiler in Java too, but why
would you want to?
> Ignoring the issue of compile-time v. run-time resolution,
and if you ignore the issue of specializing on more than one parameter,
then the whole generic function v. single dispatch issue goes away as
well, but then we're not talking about Dylan anymore.
Being able to write methods that dispatch on more than one parameter is
what distinguises generic functions from other dispatch systems. One
organizational consequence of this (as Gail Zacharias pointed out) is
that methods no longer belong to just one class. After all, since
dispatch can take place on the class of any parameter, to which class
would the method belong? In other languages this question has an obvious
answer, because dispatch can only take place on the parameter of the
class that owns the method. Because of the syntax of such languages,
programmers often forget that the owning class is an implicit parameter
("this") for the purposes of dispatch. In Dylan, there is no owning
class, so all parameters are explicit.
An additional benefit of Dylan is run-time dispatch (if you want it, and
are willing to pay the speed penalty - of course Dylan lets you
sacrifice this flexibility in exchange for execution speed when needed).
HTH,
Raf
References: