Re: Multi-methods (was Re: Overloading function calls)

Marc Wachowitz (mw@ipx2.rz.uni-mannheim.de)
6 Jun 1994 18:20:05 GMT

Tim wrote:
> Where on the spectrum from "wow! they sure did a good job on the
> optimizer!" to "wow! naive runtime multi-method dispatch is incredibly
> slow!" the truth lies is hard to say.

I don't have any experience in that area, but given the excellent work of
the Self compiler (topic of Craig Chambers' dissertation), I guess that's
mostly a comparison against the speed of Self. I've read something like a
half of C's speed - which is of course great for a purely object-oriented
language without any declarations.

[placement of multi-methods]
> Agree it's a question of adhering to good style, but as in the recent
> Syntax Wars, it's always nice if an Objectively Correct style both exists
> & is enforced by the language. Think it is worth _something_ that special
> methods have to follow certain rules today; everything's a tradeoff.

This would mean to restrict multi-methods to certain statically knowable,
though possibly dynamically callable, places. One might consider a forced
import-like feature, but I don't think it would be worth the complication
in the context of Python's dynamic nature.

> Another possibility (well, there are of course many, but I'm trying to
> restrict it to cases that aren't obviously nuts ...) is that _all_ the
> most-specific methods should be invoked.

I'm not sure whether that's a good idea in general. The problem is how to
handle the case where there are many equally specific methods on a deeper
level. On the first level it sounds reasonable to require a unique method
to be more specific than all others, since more recent types are meant to
clean up everything that came before. Without a simple and meaningful way
to order the less specific methods (i.e. not some kludge, like linearized
class precedence lists in CLOS), things will soon become unpredictable. I
would offer some interface to get at the sorted list of sets, but leave a
selection of the next method to the particular caller. Providing a common
set of selection policies would then still be possible, if the need would
arise in practice. In most cases I'd expect that the simple interface for
a selection based on explicit types would be sufficient.

------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>