Dispatching, Multimethods and the like

As it *appears* today, regular dispatching and multimethod dispatching
are going to be wired into the langauge (as appropriate). Runtime
dispatch behavior will continue to be supported, including things like
AUTOLOADER and the like.

As of January, the thinking is sub DISPATCH {} will handle runtime
dispatching behaviors, including autoloading, but easily accomodating
value-based dispatching, AOP style pre/post methods, and whatnot.

Unfortunately, Damian said that the design team isn't saying much about
this, because the semantics aren't quite worked out yet, especially with
the interaction between autoloading and other dynamic dispatching
behaviors.

Yes, this is a *big* issue.

Z.

It definitely is.

I can't speak for Perl 6 the language, but I can speak for Parrot, so I
can tell you what semantics will be available (though not necessarily
exposed) to the compiler.

For methods, each object is ultimately responsible for deciding what to
do when a method is called. Since objects generally share a class-wide
vtable, the classes are mostly responsible for dispatch. The dispatch
method can, if it wants, do *anything*. However, as some degree of
predictability is nice, the current plan is that classes will:

1) Look for the method in the class or parent. If found, it's
dispatched to. (This method may be defined as a multimethod in the class,
in which case MMD is used to determine which method of the set *in the
class only* is used)
2) Look for an AUTOLOAD method in the class or parent. If found, we
dispatch to it.
3) Look for a MMD version of the method outside of any class. If found,
do MMD

Core engine support will be in for this, since we don't want everyone to
have to bother writing code for it all. Duplicate code. Bleah. We'll
also provide method caches so we have some hope of not being horribly
slow.

By default, the system and class MMD will do class-based dispatching
only, deciding on which method to call based on the types of the
parameters. Both the class MMD method *and* the system MMD method may be
overridden if someone wants to install their own MMD scheme, though
overriding system-wide MMD stuff is always a dodgy thing. (Though no
more than any other overridden systemwide thing, I expect)

Will perl 6 support this? Dunno. Will it call for a different scheme? It
well might. Can a language completely skip the MMD stuff? It can if it
chooses, yes. What name will the dispatch sub be? Beats the heck out of
me, but then that's syntax and I don't do syntax. :)

Whoah! The wired in dispatch rules are going to be runtime dispatch
rules, but with potential compile time short circuiting where the
compiler knows enough stuff (frankly, I'm not sure I'd expect to see
compile time short circuiting in perl 6.0, maybe in 6.001 or whatever)

Yeah, but it's a late binding one.

--
Piers

That sounds about right. Perl as we know it is runtime dispatched, so
adding compiletime short circuiting sounds like a job for a new
pragma or declaration. 6.000+epsilon sounds like the right time to
introduce this feature.

Z.

Hm. Ruby has unbound methods and per-object method binding. How
does that impact Parrot's built-in dispatching behavior(s)?

Hm. Maybe the solution here isn't to fob off *all* dispatching to the
core or the program, but have loadable dispatching behaviors, much like
loadable datatypes and opcodes...

Don't know how desirable or implementable that idea would be. Or even if
it's just half-baked. But it would be interesting to play around with
things like a dispatcher that adds before: and after: methods (for AOP),
or support for programming by contract sanity checking. Worst case, a
Perl programmer might have to drop a pasm block in a class definition to
link the dirty bits together without necessarily extending the language.

Whatever happens, it's certainly one of those grey areas that lies smack
between language definition and runtime implementation...

Z.

Unbound methods are just functions, and per-object methods create a
transparent subclass for just the object being overridden. (Which is
how Ruby does it, FWIW)

Right. Hence the points of abstraction--so there's a well-defined
place to take control, along with a well documented, if not actually
sane, default. There's a lot you can do with sub/method wrapping as
well, which there's language support for in perl 6.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk