Thanks for the interesting message Steve.
Its worth remembering that the author of HiPWorks came from a mono-method
programming background, and was under severe time constraints - given more
time and experience, the percentage usages of various kinds of methods
would certainly have been different.
When you use a multi-method system you soon come to expect that you can
switch on the classes of multiple arguments as a matter of course.
Its a bit like when you start using a multiple inheritance system after
using a mono inheritance system - you soon start expecting to be able
to inherit from more than one class.
(Of course, going the other direction is harder).
Even if you never actually use multiple inheritance (or multi-methods)
the fact that it is there simplifies the conceptual space, or at least it
does for me. In real life things are rarely black or white and programming
languages should reflect this: why should classes only inherit from one thing?
and why should a method only specify the type of one argument? These seem
to be artificial implementation constraints to me.
This is a fairly weak argument for multi-methods. Steve's argument
is better - to paraphrase: There are some problems which are hard to solve
using mono-method systems, but which have clean, compact and elegant solutions
in multi-method systems.
Having said this, I must admit that I have been very cautious when choosing to
create a multi-method rather than a mono-method. Its like using a power drill
to make a hole in cardboard when you could have used a sharp pencil :-)
Jon.
|