PMCs use Vtables for almost all their functionality *and* for stuff that in Perl5 term is "magic" (or they should AFAIK).
E.g. setting the "_ro" property of a PMC (that supports it[1]) swaps in the Const$PMC vtable, where all vtable methods that would change the PMC thrown an exception.
Or: setting a PMC shared, whould swap in a vtable, that locks e.g. internal aggregate state on access. That is a non-shared PMC doesn't suffer of any locking slowdown.
Tieing will very likely swap in just another vtable and so on.
The questions are:
- Where and how should we store these vtables?
- Are these PMC variants distinct types (with class_enum and name)
- Or are these sub_types (BTW what is vtable->subtype)? E.g. hanging off from the "main" vtable?
I was going to go on about a few ways to do this, but after I did I realized that only one option is viable. So, let's try this on for size:
Vtables are chained. That means each vtable has a link to the next in the chain. It *also* means that each call into a vtable function has to pass in a pointer to the vtable the call came from so calls can be delegated properly. If we don't want this to suck down huge amounts of memory it also means that the vtable needs to be split into a vtable header and vtable function table body.
Downside there is that we have an extra parameter (somewhat pricey) to all the vtable functions.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
