public vs. private

[Keith Whitwell]

Alan Coopersmith wrote:
> Daniel Stone wrote:
> 
>> The rationale is simple: if another library is using it, it is not
>> private API, no matter how many underscores you put in front of the
>> symbol, and no matter that you put a comment saying 'this is private
>> API'.  It's simply not.
> 
> 
> In a world where both libraries always come from the same source and
> are always updated together, why not?   Of course, this is just one of
> the many things the X source has always done that modularization will
> break, but such is the madness we're heading towards.
> 

There are good technical reasons for restricting the visibility of 
non-"public" symbols - code size reduction, improvement in startup times 
of linked applications, etc, so that's one reason why not.

Another reason why not is that unless these symbols are marked up and 
identified in the "victim" libraries, coders operating on the "victim" 
code won't be aware that it is actually utilized as an interface by code 
elsewhere, and are in danger of unwittingly breaking compatiblity on 
these pseudo-interfaces, perhaps in subtle ways that won't be recognized 
in testing.  So, two reasons.

A final reason is just plain good taste.  If it's an interface, make it 
an interface, if it's not - what is it?  You wouldn't (hopefully) let 
code like this into X.org now, why protect the stuff that made it in 
when standards were lower?

Historic bad coding practices don't self-justify their own continuation.

Keith