Dan Sugalski wrote:
We need the ability to layer PMCs. Nothing new, we need something of the sort for transparent read-only-ness and probably thread-safety (though we don't have to do it that way) and folks are going to want to do undoable custom vtable layering. While we don't *have* to let 'em do that, I'm inclined to if only because a good general-purpose mechanism will make things less error-prone overall.

Turn the vtable field into an array (C-style--an array, not an Array), and add an INTVAL C<layerno> parameter to all vtable functions. vtable[0] gets all calls, and can pass them on to vtable[1], etc. etc. This requires an additional parameter to each vtable function, but keeps you from having to allocate an entire PMC for each layer, at the cost of possibly reallocating the array when you want to push a new layer. (A smart system would probably allocate a couple extra slots, to cover the common layering cases.)


A linked list of vtables is also possible, but you'd probably need to pass the C<next> pointer to all of the vtable methods, so it doesn't keep you from needing an extra parameter.

If these are untenable, I vote for "allocate a new PMC, copy the old PMC's guts into it, and set up the layer in the old PMC". External references to the PMC are more important than internal ones.

--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker

Oceania has always been at war with Eastasia.

Reply via email to