Things start to get interesting. The first two vtable slots are gone. The dispatch for the C<bxor> PMC opcodes is now down fully per MMD.
The MMD_BXOR and MMD_BXOR_INT MMD slots are just adjacent entries in the function table. This is the simplest implementation and provides good cache locality for similar functions.
I think it's now time to review the code a bit and check if the whole concept is sane.
Looks OK.
Interesting is the dispatch inside objects. These have a delegate vtable which runs a PASM function. But it could be redispatched before by installing an appropriate MMD version.
I think we're going to want to think about this some. What was the basic vtable dispatch function that got delegated is now going to be the default function for the object, and I think we can leave it at that.
It does mean that we're going to need to get the notification system in so we can catch updates to the namespaces. I'll split the event/IO doc I'm working on into pieces and get that out so we can hit this next.
Finally we should probably rename the VTABLE_<function> macros to e.g.
DISPATCH_<function> which is either the current vtable call or the mmd_dispatch_<signature>(... ,MMD_<type>) function. --Or provide two sets of macros, i.e. have additionally MMD_DISPATCH_<function> macros?
See classes/ref.pmc for a current workaround and include/parrot/vtable.h for the current macros.
I think going with the DISPATCH_<function> macros is the way to go for this.
It all looks just fine, so I'm all for whacking it in for the rest of the vtable slots and getting this done in one go.
After that maybe we can beat ICU into submission and cut a 0.1.1 release. :)
--
Dan--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
