You can clone with
HTTPS or Subversion.
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.
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.