Deprecations for 3.0

[Nick Wellnhofer]

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