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)?
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 tohave 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
