Deprecations for 3.0

[Peter Lobsinger]

On Fri, Sep 17, 2010 at 8:12 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> On Fri, Sep 17, 2010 at 1:54 AM, Peter Lobsinger <plobsing at gmail.com> 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.