Alek Storm wrote:
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.
Take a step back and explain your motivations for adding
'add_vtable_method'?
The :vtable pragma is necessary for defining a .sub as an overridden
vtable function in PIR code. If you had a replacement in mind, run it by
the list and we'll discuss it, but we can't just eliminate the feature.
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.
Why would other object systems not use vtable overriding? Vtable
overriding is a Parrot feature, it's the way high-level classes
implement their interactions with the virtual machine at a low level.
Different object systems having different semantics doesn't change the
fact that they implement those semantics using a combination of vtable
functions and methods.
If you want to override vtable methods for built-in PMCs
such
as Integer, you need to implement PMC subclassing for PDD15 ;)
Which is part of the spec.
Allison
