On Fri, Sep 17, 2010 at 11:43 AM, Andrew Whitworth <[email protected]> wrote: > On Fri, Sep 17, 2010 at 11:18 AM, Peter Lobsinger <[email protected]> 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. > > Ah, I see where my problem is. Parrot used to have real write-barrier > macros GC_WRITE_BARRIER() and similar things. I see now that those > macros do not appear to be present anymore. I agree with you that > SET_ATTR and GET_ATTR macros are not sufficient for this purpose. We > previously did have (and will likely have again) better macros which > will be sufficient. > > If we need to add a deprecation note for adding new macros, we can do that.
I think we need both a deprecation notice and stub implementations of these macros by 2.9. Being able to assign simply by using 'x = y' is pretty much taken for granted, and we'll be braking that assumption. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
