Deprecate VTABLE_can #675

Closed
Whiteknight opened this Issue Mar 7, 2011 · 3 comments

Projects

None yet

2 participants

@Whiteknight

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.

Originally http://trac.parrot.org/parrot/ticket/2042

@cotto
cotto commented Mar 8, 2011

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 May 7, 2012
@Whiteknight

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.

@Whiteknight

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 Mar 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment