[arc-discuss] When should interfaces be private?

[Darren Reed]

Sebastien Roy wrote:
...
> So, the distinction between what is "Private" and what is "Public" is
> very much appropriate and required in order to sanely manage change in
> complex software systems, and has absolutely nothing to do with whether
> or not the software is open-source.  The issue that Darren raised wasn't
> intended to result in the removal of the Private interface taxonomy, but
> in better managing how that taxonomy is applied (at least that's how I
> took it).  The original point is valid, IMO.
>   

Yes, you're right about why I raised this.

And thinking about this has led me to two suggestions:
1) in the interest of time (and perhaps to push projects to being
   less private), PSARC should only review the details of interfaces
   that are volatile, uncommitted or committed;

2) PSARC should consider that a project presenting interfaces that
   are private amongst the design materials a "bug" - ie if a project has
   a large document that includes several pages about how the interfaces
   for X work but X is private, either remove X from the document or
   update X to volatile.

The challenge is that ofter explaining how Y works (or its architecture) can
require doing so for X....in which case I think I'd like to see 
drag-along to
upgrade commitment rather than removal.

Hmm, maybe they're both different sides of the same coin?

For the most part, I think this nearly always happens anyway, as projects
typically don't want ARC interfearence in private matters :)

Cheers,
Darren