[sniping to reduce verbiage]

Yes, that's what I meant by the original vtable. :-)

Going back to the idea of generating these vtables on the fly (and caching
them): each instance of a vtable gets a void* closure in the vtable itself,
so at a certain expense in extra vtables, one could hang a structure off
of that that includes a pointer to the original vtable. E.g. (pseudo-code)

if (we don't have a tracing PerlInt in our cache) {
     TracePerlIntVtable = clone_vtable(interp, TraceVtable);
     vtable_set_data(interp, TracePerlIntVtable, PerlIntVtable);
     cache(TracePerlIntVtable);

TraceVtable::get_number(INTERP, self) {
     FLOATVAL f;
// I don't have the headers in front of me to get the right field names...
     VTABLE *my_vtbl =  self->vtable;
     VTABLE *old_vtbl = my_vtbl->private;

     self->vtable = old_vtbl;
     f = self->vtable->get_number(interp, self);
     TRACE("%p->get_number() = %f", self, f);
     self->vtable = my_vtbl;

     return f;

With slightly more complicated closures, most of the listed uses can use this
method. It's memory-heavy, but not too bad if we need a fair number of PMCs of
each wrapped type and the cost gets amortized over them. And this does save an
argument to every PMC function and just makes the wrapping classes pay. Where
it's suboptimal is for classes like autolocking that really want a closure of
their own on every PMC. But then again, that would again probably get into
issues of data collisions (except for locking, which has its own reserved area).

Just some thoughts.

-- BKS