Brian T Rice <water at tunes.org> wrote:
> On Mon, 16 Jun 2003, Stephane Ducasse wrote:
> 
> > I worked with CLOS during 4 years and I did not find the advantage of
> > multi dispatch. You know this is like multiple inheritance you need that
> > in 5% of the case and it makes the language much more complex for the
> > rest 95%
> >
> > Stef
> 
> Which is why we've made sure in Slate that the dispatch overhead only
> scales up from the normal overhead with the more complicated usages
> (which, again, is rare). Encapsulating it within message-sends, though,
> means that inlining and other optimizations are more easily done.
> 
> And we don't use "generic functions": no compromises here. :P
> 

I don't think Stephan was talking about speed complexity, but semantic
complexity.  It may be harder on the human to work with programs that
have multiple dispatch.  It is definitely harder to make programming
tools, though how much harder depends on how complex your dispatch
algorithm is.  I suspect it is quite hard on the compiler, too, if you
allow dispatches on deep structure and you also keep allowing classes to
be redefined at runtime.

I don't find hand-coded double-disptach to be ugly at all, but then I've
been writing a lot of Smalltalk code.  :)  I do have to admit that
multi-dispatch is sometimes *very* nice.  In particular, it lets you
write tree-walking code very elegantly.  It really bothers me, though,
that multi-dispatched methods are dependent on the concrete structure of
multiple classes in order to function properly.  But then again, is it
really so bad if a programmer explicitly wants to "early bind" some part
of the structure of their program?  It is their choice, after all.

I really don't have a good feel for whether multiple dispatch would pay
its own way.  I would mildly vote to leave it out of a Smalltalk-like
langauge simply in order to stay true to Smalltalk's philosophy of
having a tiny number of orthogonal constructs, that allow you to write
anything without too much trouble.


Lex