Deprecations for 3.0

[kjstol]

On Fri, Sep 17, 2010 at 6:54 AM, Peter Lobsinger <plobsing at gmail.com> wrote:
> Hi,
>
> As noted this week on #ps, some of the goals we have for 3.0 require
> that some existing functionality be deprecated before they can be
> complete. The 2.9 supported release next month is the last chance to
> get these deprecations in time to allow our 3.0 goals to be met, so we
> need to start thinking about this now.
>
> Hereare  some of the milestones for 3.0 and possible deprecation concerns:
>
> 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.
>     * we need a more general way of indicating reference creation and
> we need to require that users use it
>  * Copying:
>     * object motion might require explicit pinning of objects with
> references on the C stack (currently handled magically by stack
> walking)
>
> lvalue semantics:
>  * not sure if we have a concrete plan on this. do we have any
> planned/desired changes in this area that would be blocked by
> deprecation?
>
> native typed lexicals:
>  * this is purely adding functionality
>  * likely doesn't need deprecations.
>
> concurrency:
>  * not really sure where we are or what lies ahead here. anyone care
> to forecast?
>
> pirc:
>  * incompatibilities with imcc (if any) likely need deprecations
>  * stalled, so these incompatibilities are unknown at the moment

I could point out a number of differences if necessary (can't come up
with a long list from the top of my head). It's not so much that pirc
would have to be changed to act more like IMCC; rather, IMCC does not
comply with PDD19, the spec. of PIR... and most of these issues, if
not all, have been fixed in pirc. These issues are pretty much all
syntactical I think.

kjs