Deprecations for 3.0

[Andrew Whitworth]

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.

> concurrency:
>  * not really sure where we are or what lies ahead here. anyone care
> to forecast?

All existing threading machinery should probably be listed as
deprecated since the vast majority of it is going to need to be either
completely ripped-out or radically modified in the months following
3.0.  This includes the PMC types (Task, Timer, ParrotThread, whatever
else I am forgetting) and the relevant opcodes as well. Also, and I
need to look over some code first, I think the current callback
mechanism needs to be either radically changed or completely killed
and rewritten too. Some of this stuff may remain unchanged, but I
think that is a minority subset if we are really dedicated to doing
threading right.

--Andrew Whitworth