On Fri, Sep 17, 2010 at 8:12 AM, Andrew Whitworth <[email protected]> wrote: > On Fri, Sep 17, 2010 at 1:54 AM, Peter Lobsinger <[email protected]> wrote: >> GC: >> * Generational: >> * requires barriers to handle bookkeeping at reference creation >> * existing object attribute access barriers are: >> (a) unwieldy and therefore not used consistently >> (b) insufficient to support more complicated uses. a good >> example is PMC aggregates. > > I mentioned in #ps, but I don't think that this requires a > deprecation. The write barriers already exist and are documented on > their purpose and their uses. What we would be changing is the level > of enforcement in their use, which doesn't really seem like a > deprecation policy issue to me. We can add in a note if people want.
So why haven't you used them in either parrot-data-structures or parrot-linear-algebra? 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. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
