context_pmc3 branch and backward compatibility.

[Andrew Whitworth]

On Mon, Aug 24, 2009 at 3:54 AM, chromatic<chromatic at wgz.org> 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