I think that need not be as horrible as in Cecil when one doesn't use
multi-methods for everything. (Btw, Common-Lisp programmers are using
multi-methods as well, and it may be well worth asking there. I'm not
so sure whether it's so difficult to come up with a reasonable scheme
for method placement etc. in the common cases.)
> + Even in Cecil, which has a great deal of static type info available at
> compile time, decent speed requires sophisticated profile-based
> feedback to the compiler, specifically aimed at speeding MM-style
> dispatch searches.
This is again with a very different expectation about speed than any-
one using Python today might even dream of. I don't think it would be
extremely difficult to optimize much of that without static info etc.
(asking experienced CLOS hackers might again be useful). E.g. much of
the inheritance-related stuff could be memorized after it's first use
if there are hooks to be informed of method (re-)definitions (to make
the information consitent again), and the deeper level of the list is
only needed rarely (if my expectation is true). Nothing forces one to
compute it fully in every case. Remember that coercions are also just
a way to minimize interfaces, and you can always get rid of the over-
head by defining the appropriate method signatures (finding these for
a given program should usually be relatively independent from input),
possibly even automatically (replacing the coercion-definition with a
different function, but keeping the same simplicity in the statically
observable program).
Given the complexity of the issue, I'm mostly agreeing with Tim, that
we better shouldn't (yet) build multi-methods deeply into Python.
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>