Re: Dispatching, Multimethods and the like
Adam Turoff [EMAIL PROTECTED] writes:
Damian just got finished his YAPC opening talk, and managed to allude
to dispatching and autoloading.
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.
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)
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.
Yeah, but it's a late binding one.
--
Piers
Re: Dispatching, Multimethods and the like
On Tue, Jun 17, 2003 at 09:44:52AM -0400, Piers Cawley wrote: Adam Turoff [EMAIL PROTECTED] writes: 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. 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) 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.
Re: Dispatching, Multimethods and the like
On Mon, Jun 16, 2003 at 06:31:54PM -, Dan Sugalski wrote: 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*. Hm. Ruby has unbound methods and per-object method binding. How does that impact Parrot's built-in dispatching behavior(s)? 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. 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.
Re: Dispatching, Multimethods and the like
At 10:37 AM -0400 6/17/03, Adam Turoff wrote: On Mon, Jun 16, 2003 at 06:31:54PM -, Dan Sugalski wrote: 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*. Hm. Ruby has unbound methods and per-object method binding. How does that impact Parrot's built-in dispatching behavior(s)? 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) 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. 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... 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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
