(with one major caveat: if the _vtable_ functions try to use the PMC's address as an index into some data structure, things will go wrong since the PMC the base vtable functions get no longer has the same address as the logical PMC; if external things want to do so, that's fine though, since the logical PMC's address hasn't changed). After all, AIUI no one but the vtable functions is supposed to be poking inside the PMC, and the wrapper PMC (which happens to have the same address as the original PMC) will of course pass the new wrapped PMC down when it redispatches.
Well... I'm not sure that the wrapped PMC is what gets passed on, which is where things get tricky.
If it does, then access to the internal bits works out just fine. On the other hand, any vtable redispatch (of which there's a not-inconsiderable amount) doesn't work out right. For example, for an Integer PMC with bytecode vtable functions:
.sub __set_string_native prototyped, method
.param string value
$I0 = value
self = $I0
.endif we pass in the inner PMC to that, and someone's thrown a wrapper that intercepts the integer set then the intercept wouldn't get triggered, and I think that's probably a bad thing.
Unfortunately doing this makes getting to the guts of the PMC tricky. It also means you can only have one of each layer type layering a PMC, since all the non-terminal layers will have to search down from the top until they find the right PMC, which'll involve doing vtable type comparisons or something like that, which isn't too good either.
I'm not sure there's a good answer here, and *something* is going to take a speed hit. (Passing in the base pmc pointer along with the current pmc pointer has its own costs, since extra parameters aren't free either) I'm just not sure where we want that hit to be.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
