On Sunday 23 August 2009 19:34:56 Allison Randal wrote: > > In context_pmc3 branch I converted direct using of Parrot_Context* to > > Context PMC. Unfortunately it will break any HLL which depend on current > > Parrot_Context struct.
> > So, question is "Does deprecation policy cover this situation and we > > have to live with refcounted Context which causes memory leaks, > > segfaults and eat kittens for breakfast until next deprecation cycle"? > > Yes, it means it has to wait. Which gives you plenty of time to add a > deprecation notice, and think about a sane migration strategy for the > users. And, to do performance testing, to see if the change will help or > hurt us. I think that takes backwards compatibility too far. * We've never advertised the contents or layout of Parrot_Context as visible (or even documented) outside of the core. * We categorically refuse to support functions not marked as exported and API functions; why support anything other than opaque data structures? * We've changed struct layouts (and even existences) without deprecation notices before. * If this becomes part of the policy, we can't merge most of the outstanding branches (pluggable_runcores and anything PCC rewiring especially) and we'll have to unmerge several branches (UnionVal removal and the fixed-size and lazy GC allocators) until 2.0. I'm not sure that's feasable. I'm sympathetic to languages which will need changes, but they're taking big risks by poking into the guts of Parrot itself we've never documented as available for external projects. We don't even have an API for messing with these internals -- delaying the availability of such an API for another five months will only increase the pain. Alternately, we *could* release 1.4.1 which contains deprecation notices for all of these changes. I'm not sure I'm kidding about that. -- c _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
