[arc-discuss] When should interfaces be private?

[John Plocher]

Darren Reed wrote:
> For people outside ON, I'd contend that Consolidation Private is the 
> same as Project Private.

And all that means is "warning - implementation detail ahead, not
intended to be used as an interface into this functionality!"

Nothing here about secret or forbidden; the implication is that if
you choose to make a dependency on this detail, you will have to
/react/ when it changes, rather than being part of the proactive
"think before doing" regime we try to use.

Inside of ON, this is "business as usual" - you change something
and you are *expected* to ferret out and fix all the internal-to-ON
consumers of the thing you changed, even if/when the thing you
changed was Private.  This is hard, which is why we have variations
on the Private theme - shared among friends private, shared among
close family private and only shared with my spouse private :-)

The only thing that changes in FOSS-ON is the pool of developers
in the friends and family buckets gets a bit larger, not that our
classifications or expectations change drastically.

The difference between *Private and Volatile is the scope of closure;
when you change your *Private interface, we expect you to be able
to fix the closure of ALL dependencies as you integrate; with a
public exposure like Volatile, you can't, and there *will* be consumers
who get burned.

Bottom line for me:  If it *is* an implementation detail, *Private
is the right answer.  If it is a new intended-to-be-public experiment,
then it shouldn't remain *Private very long, because (other than
being an oxymoron) private public things always seem to cause us
problems.

   -John