Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Deprecate VTABLE_can #675

Whiteknight opened this Issue · 3 comments

2 participants


VTABLE_can is defined in two places: object.pmc and default.pmc. In both cases, it performs exactly this operation:

return !PMC_IS_NULL(VTABLE_find_method(interp, self, name));

Also, VTABLE_can is not able (yet) to be overridden from PIR code, which means that the vast majority of classes written by users will always have this same exact default behavior.

I suggest we deprecate and remove VTABLE_can. The "can" PIR op can remain, but should call VTABLE_find_method directly.



We currently have ops for find_method and can, and VTABLE slots for find_method and can. I'd be amenable to having only a find_method op, but we also have to consider how this would affect users. If the burden on Rakudo and Partcl (and anyone else using these ops/VTABLE slots) isn't too bad, let's put the VTABLE slots and the "can" op through a deprecation cycle.

@Whiteknight Whiteknight was assigned

I have created the whiteknight/gh_675 branch to remove this vtable. In the branch the VTABLE has been removed and the ops have been reimplemented to use find_method directly. All coretests pass.


I have merged the whiteknight/gh_675 branch to master. The VTABLE_can is now gone. The can opcode and all user-facing code should remain the same. NQP and Rakudo build and test without any problems This issue is closed now.

@Whiteknight Whiteknight removed their assignment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.