Nope, not objects, but at least it's partway there. This bit is about making method calls.

We've two issues on the front end. First, we need to be able to get a method PMC from an object, in those cases where we want to save that for later, and second we need to call methods. So, here's how we're going to do it.

We add three ops, findmeth, callmeth and callmethcc. (The latter just automatically takes a continuation for the following op and stashes it in P2, while the former assumes one has been put in P2 already) They all find a method PMC based on the object and method name already loaded. The call ops then call
that PMC's invoke vtable entry, which acts as normal.


So the sequence is:

P0 = P2->find_method(interpreter, P2);

and for the call ops, then:

   dest = P0->invoke(interpreter, P0, expr NEXT());
   goto ADDRESS(dest);

The returned method PMC handles anything fancy--multimethod dispatch and whatnot. We need base engine support for MMD and method caching, amongst other things, but we can get to that later.

The method PMC returned by findmeth can be invoked as a regular subroutine, so we're fine there. I'm not, at the moment, leaning towards a separate "invoke this pre-fetched PMC sub as a method" op, since we're not passing on any information as to how a PMC is invoked outside of there being an object in P2, but I can be convinced otherwise if we can make a good case for languages actually using that information.

I'm thinking at this point, since we need to add the call and callcc ops as it is, that we should probably have tail versions of all these ops, which just puts the various bits from the continuation in P1 back before making the call, but we can talk about that later if we want.
--
Dan


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to