On 17/09/2010 17:18, Peter Lobsinger wrote:
But more to the point, they are insufficient for handling aggregates.
If a PMC cointaining ATTR isn't a simple PMC*, but something more
complicated (like PMC**), the whole thing falls appart. Clearly you
can still have one PMC reference another by these means, but the
SET_ATTR and GET_ATTR macros cannot express these assignments.
Try rewriting ResizablePMCArray or Hash or PMCMatrix2D or any
aggregate to use them. They don't work in these cases. We need
something more general.
Yes, we will need an explicit barrier for aggregate PMCs and every other
PMC that stores PMC or STRING pointers hidden somewhere inside. But we
should still use SET_ATTR wherever it's possible. There are tons of
places where there is no reason not to use SET_ATTR but we still use
PARROT_xxx(SELF)->pmc_attr directly.
Nick
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
