Skip to content
This repository

Deprecate VTABLE_can #675

Closed
Whiteknight opened this Issue March 07, 2011 · 3 comments

2 participants

Andrew Whitworth cotto
Andrew Whitworth
Owner

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
Owner
cotto commented March 07, 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.

Andrew Whitworth
Owner

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.

Andrew Whitworth
Owner

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.

Andrew Whitworth Whiteknight closed this May 16, 2012
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.