On Mon, Aug 24, 2009 at 3:54 AM, chromatic<[email protected]> wrote: > 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.
I agree with this 100%, we can't be obligated to preserve everything internal to Parrot just because a user has broken encapsulation and used it directly. After the pmc_sans_unionval branch merged there was a breakage in Rakudo specifically because they were poking into structure guts internally instead of using macros that Parrot provides to access them in a safe way. In some ways these problems are our fault because we don't always provide proper encapsulation (API functions or macros) for some of these things, especially things like Parrot_Context. Alternatively we don't provide these kinds of things because we don't want people poking at these structures directly in the first place. If people want to break our encapsulation and poke around in Parrot guts, we can't be tied down by that. If people need access to features that we don't currently have an encapsulated interface, they can ask for one to be provided (and in many cases it will be trivial to add and document them). > * 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. The lazy GC allocator doesn't really change any code that is user-visible, all those structures are absolutely private to /src/gc/*. The UnionVal stuff did break Rakudo as I mentioned, but only because they didn't use the right encapsulation interface. Runcores and PCC internals are absolutely not things that anybody should be poking at. > 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. Agreed, and if they do want or need access to things that we have never provided, they can ask for a new interface to be added. We can add new interface like this very quickly, and list it as experimental so we don't get stuck if it turns out not to be the right thing. I'm sure that the context_pmc3 branch needs some eyes on it, some testing, etc. It does need some time for us to become confident in it's changes. 5 Months is far too much time for this, and we shouldn't have to wait that long. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
