On Mon, Jun 16, 2003 at 06:31:54PM -0000, 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.
