Christoph Otto via RT wrote:
I'm running into a snag trying to implement this. It turns out that
many lines which use the PMC_x_val macros use them on different types of
PMCs, especially parents and children (e.g. FixedPMCArray and
ResizablePMCArray). There are also some instances where the PMCs with a
related purpose but no inheritance (e.g. RetContinuation and
ExceptionHandler) have the unionval used in the same way on a line of code.
What's the right way to fix these cases to use the GETATTR/SETATTR macros?
I have a file that lists these, which I'll be sticking on the wiki later
tonight.
Here's the more detailed version:
Thanks to Infinoid++, I was able to follow particle's recommendation earlier
in the thread and modify the PMC_x_val macros to record some information at
runtime. This will make the cage task *much* more approachable and
parallelizable, but it also exposes places where code makes promiscuous
assumptions about PMC internals.
The referenced files were generated by modifying include/parrot/pobj.h [1],
then building and testing Parrot and any currently maintained HLLs that use
custom PMCs. The results are on trac, sorted by file [2] and by PMC [3]. I
did this to help clarify how the UnionVal macros would need to be converted to
GETATTR/SETATTR macros, since the latter are PMC-specific. The files are
generated from r34501 and can be regenerated as needed.
The problem with using ATTRs in their current state is that, depending on
control flow, a given instance of a PMC_x_val may be called with several
different PMC types (see src/hash.c:1045 in [2] for an extreme case). This is
fairly common and makes ATTRs unusable for any PMCs whose UnionVals are
twiddled by common code.
One solution to this would be to make ATTRs follow the inheritance chain so
the following code works:
PMC *foo = new_pmc(INTERP, enum_class_Foo); /*Foo has no ATTRs, extends Bar*/
INTVAL baz; /*Bar has a "baz" ATTR*/
GETATTR_Bar_baz(INTERP, foo, baz);
I'm not attached to any particular solution, but it's clear that the migration
away from the PMC UnionVal can't happen without some kind of significant change.
[1] http://xrl.us/becsw4 (diff)
[2] http://xrl.us/becswu (csv, sorted by source code file)
[3] http://xrl.us/becsww (csv, sorted by PMC type)
