On 5/3/07, Allison Randal <[EMAIL PROTECTED]> wrote:
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.
I assumed it would be discussed when I submitted the patch. This ticket just came up first, that's all. If we decide to add 'add_vtable_method', then the :vtable pragma becomes redundant. In fact, the only reason we need the :method pragma is because it modifies the sub's parameters (if it didn't, we could eliminate :method and just call 'add_method' on the class).
I can see potentially see adding an 'add_vtable' vtable function, parallel
to add_method, add_attribute, etc. So you are in favor of it? Matt Diephouse (via RT) wrote:
After the recent decoupling of vtable functions from methods (with the addition of the :vtable pragma), why would you want to re-couple them? I see the two as distinct features, each with their own uses. Sometimes there's shared behavior, but there ought to be the ability to have them behave differently.
Ditto. Just because we can squeeze two separate features into 'add_method' doesn't mean we should. After all, Allison said before that having vtable methods that aren't visible as normal methods is the most common usage, and the current spec requires an extra parameter to do that. Having 'add_method' and 'add_vtable_method' does not.
> 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.
Vtable overriding at the C level is a Parrot feature. Vtable overriding at the PIR level is a feature of Parrot's default object system. If someone decides not to inherit from Object and Class, they don't get PIR vtable overriding. We're using roles for PMCs, not inheritance, so all a PMC has to do is act like an Object, not necessarily be one. This means they either implement their vtable methods in C, or provide their own mechanism for vtable overriding, and then define them in PIR. If they choose not to do it, that's their choice.
> 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.
Yup. I was just pointing out that it doesn't work yet, in case that was what he was looking for. -- Alek Storm
