Deprecations for 3.0

[Peter Lobsinger]

On Fri, Sep 17, 2010 at 11:43 AM, Andrew Whitworth
<wknight8111 at gmail.com> wrote:
> On Fri, Sep 17, 2010 at 11:18 AM, Peter Lobsinger <plobsing at gmail.com> 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.