On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
> Multimethod dispatch?
> Adam Turoff asked if multimethod dispatch (MMD) was really *the* Right
> Thing (it's definitely *a* Right Thing) and suggested that it would be
> more Perlish to allow the programmer to override the dispatcher,
> allowing for all sorts of more or less cunning dispatch mechanisms
> (which isn't to say we could still have MMD tightly integrated, but it
> wouldn't be the *only* alternative to simple single dispatch). Luke
> Palmer gets the "Pointy End Grandma" award for pointing out that Perl 6
> is a '"real" programming language now' (as Adam pointed out, Perl's been
> a 'real' programming language for years), inspiring a particularly pithy
> bit of Cozeny. As far as I can tell, Adam wants to be able to dispatch
> on the runtime value of a parameter as well as on its runtime type (he's
> not alone in this). Right now you either have to do this explicitly in
> the body of the subroutine, or work out the correct macromantic
> incantations needed to allow the programmer to use 'nice' syntax for
> specifying such dispatch.
>
> Assuming I'm not misunderstanding what Adam is after, this has come up
> before (I think I asked about value based dispatch a few months back)
> and I can't remember if the decision was that MMD didn't extend to
> dispatching based on value, or if that decision hasn't been taken yet.
> If it's not been taken, I still want to be able to do
>
> multi factorial (0) { 1 }
> multi factorial ($n) { $n * factorial($n - 1) }
That's pretty much correct.
I've been musing on dispatching over the last week, and I've come
up with a few scenarios:
- pure type-based (match a method's signature, modulo superclasses)
- pure value-based (scalars with specific values)
- mixed-mode (RightMouseClick class, with 'control' modifier set/unset)
- pre-/post- methods; chains of pre-/post- methods
- AOP-style pre-/post- methods that can come and go at runtime
- Eiffel-style contract checking/enforcement
- roll-your-own inheritance mechanisms (see NEXT.pm)
I've also considered "side-effect based dispatching" for lack of a better
term: Consider an object with a whole gaggle of methods that need to check
whether the database is up before continuing. All of them fail similarly
with a "database is down" error. Why *not* factor that out into a
different set of multimethods that execute only when the database is down?
Now consider what happens if the database handles are not parameters to
each method call, but slots in the object or stored globally...
There are a few other, admittedly weird scenarios where this kind of
behavior would be desirable. All of them exhibit an AOP-ish quality.
Anyway, as Piers summarized, my concern is that if there's only two types
of dispatching, it may be artificially limiting. I'm guessing that if I
can think of three dispatching behaviors, then there may be five, and if
there really are five then there just might be as many as ten or more.
Therefore the simple dispatch/type-based MMD dispatch duality limits more
than it empowers.
I don't think this is really a problem to be solved in the domain of
macro expansion or syntactic warpage. Writing classes to handle these
rules feels like the way to go. Whether or not MMD as it's been sketched
is hardwired into the language (e.g. for performance) is less important to
me than the ability to plug in different (levels of) dispatching behaviors.
Z.
