Parrot wrote:
#218: can't sort a PIR subclass of an RPA.
-------------------------+--------------------------------------------------
Reporter: coke | Owner: whiteknight
Type: bug | Status: reopened
Priority: normal | Milestone: 1.1
Component: core | Version:
Severity: high | Resolution:
Keywords: tcl blocker | Lang:
Patch: | Platform: all
-------------------------+--------------------------------------------------
Comment(by whiteknight):
Okay, I talked with pmichaud++ and jonathan++ tonight, and I've come up
with a bit of a game plan that we can use to resolve this issue (although
it will take at least one deprecation cycle):
1) Change the Sub, Continuation, EventHandler, and other PMCs to not rely
on get_addr and set_addr anymore. This will help to remove the very-
volatile get_pointer and set_pointer VTABLEs from being exposed to PIR
code (which can easily create segfaults if misused with other types of
PMCs that don't expect it).
2) Remove the set_addr opcode entirely.
3) Change the get_addr opcode to return the memory address of the PMC
passed into it. This is needed by Rakudo at least, and probably by other
HLLs as well eventually.
4) Change FixedPMCArray (and maybe other array PMCs) to use get_pointer to
return a pointer to the underlying C array. This will improve
encapsulation and allow subclassed types to inherit the sort() method
properly.
Does this plan sound decent?
The only hole is the question of what the Sub, Continuation, etc will use in
place of get/set_addr. Other than that, it sounds like a very good idea to
keep get/set_pointer inaccessible from PIR.
+1
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
