On 5/2/07, via RT Matt Diephouse <[EMAIL PROTECTED] > wrote:
There's no real way to set a vtable function at runtime. It's
possible to use the PIR compiler to eval a new function, but there's
no way to take an existing sub and add it as a vtable function[1].
Before :vtable, this operation simply meant adding the sub to the new
namespace under the right name. But since that's going away, we need
a new way to do things.
I suspect we need some sort of set_vtable opcode.
set_vtable ['Foo'; 'Bar'], 'get_string', $P0
I'm almost done with the PDD15 implementation of vtable overriding. It adds
the 'add_vtable_method' PCCMETHOD to Class, but also adds methods to the
vtable in 'add_method', if they have the :vtable pragma set, like the old
object system. I kept this capability for compatibility, but I'd love to
remove it, along with the :vtable pragma. I'm very against adding a new
opcode, since this is exactly what PCCMETHODs, and, eventually, PMC roles
are designed for, though the sentiment is the same.
Maybe there should be set_root_vtable and set_hll_vtable variants to
go along with to match the set_*global opcodes.
I'm not sure how this should interact with PMCs or whether there
should be get_*vtable opcodes. It should be easy enough to return a
Bound_NCI PMC if the user requests a vtable function from a PMC.
How PMCs interact with vtable methods in PIR is dependent on the object
system used. The default (PDD15) object system utilizes vtable overriding,
but other object systems have different semantics. This means, while PIR
code can wrap PMCs in their own object system, we can't make all PMCs
object-aware. If you want to override vtable methods for built-in PMCs such
as Integer, you need to implement PMC subclassing for PDD15 ;)
--
Alek Storm
