Deprecations for 3.0
wellnhofer at aevum.de
Fri Sep 17 15:35:01 UTC 2010
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
More information about the parrot-dev