This will have to wait until after the release, of course, but the ponie
stuff has brought up a *really* good point that needs addressing. There's
no good way to get or set a generic pointer in a PMC. Right now we're
either cheating (by poking into the guts of a PMC) or hijacking an exiting
entry (like, say, the get/set int keyed int entries) neither of which is
really a good option for extensions.
So, once the screaming pumpkin departs, I want to add these two entries to
the vtable:
(void *)get_pointer()
void set_pointer(void *)
with their keyed variants. The default action will be to pitch an
exception, and there won't be a way from bytecode to access these, but
they should provide extension code with backing custom C PMC code to
handle the case of fully-functional PMCs wraping some other, non-parrot
value.
The immediate use case here is wrapping as perl 5 xV. (a scalar, hash, or
array) These things all express all the get/set functionality that PMC
vtables have, which means there's no way for an extension to actually put
a pointer to the xV thing (and, more importantly, *change* it at runtime)
without bypassing the API access controls we have in, and I'd rather that
not happen.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
