public vs. private
Mike A. Harris
mharris at redhat.com
Tue Feb 1 10:28:20 PST 2005
On Tue, 1 Feb 2005, 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.
I'd have to disagree with this statement. A well designed API
should have documented public interfaces, and private internal
interfaces that aren't used by anything except the internal code
that they're intended for. If internal symbols must be used by
some other API implementation, or are of a large enough benefit
to another API, then perhaps they _should_ be public altogether.
The public/private distinction is important IMHO. It shouldn't
matter wether something comes with X and is using an API entry
point, or wether it comes with X and is using an entry point
IMHO.
There may be legacy behind the way X does things now, but this is
hideous, and I definitely am in agreement with Daniel on that
point, as I did not object to the change that was made, rather I
objected to the fact that it was made without any prior public
discussion, which I feel is really important to the success of
the project.
It's nice to see such changes discussed ahead of time because
voluntary peer-review is always a good thing, and people often
have alternative suggestions, or bring points forth that others
might not have considered. It's also good to see things
discussed ahead of time, so people can see the
rationale/justification for a change, and know that there
actually was one.
--
Mike A. Harris, Systems Engineer - X11 Development team, Red Hat Canada, Ltd.
IT executives rate Red Hat #1 for value: http://www.redhat.com/promo/vendor
More information about the xorg
mailing list