Re: To gh_ or not to gh_?

[Lars J. Aas]

On Tue, May 15, 2001 at 07:27:30PM +0100, Neil Jerram wrote:
: >>>>> "Lars" == Lars J Aas <address@hidden> writes:
:     Lars> Yes, that's what I meant.  If you use opaque datatypes and
:     Lars> access methods you will generally have a more stable
:     Lars> interface (easy to maintain binary compatibility compared to
:     Lars> when exposing internals).  If you check out the libtool
:     Lars> manual, there are some useful hints related to deciding on
:     Lars> library interfaces.  I'd add some points to the list though
:     Lars> (like writing your interfaces in a "functional" way so you
:     Lars> can translate them to scheme without using call-with-values
:     Lars> :).
: 
: Thanks - in such cases, I agree.  But what about cases where you want
: to use a struct to group related parameters, and that struct is
: documented as part of the interface.  E.g. struct sockaddr_in in the
: sockets interface, or XEvent in Xlib?  Would you argue against those
: as well?

How is the sockaddr_in working with IPv6 (I don't know so I'm just
wondering).  As for XEvents, I figure the XInput extension to X (which I
also don't know much about) was needed because of lack of flexibility
in that area.  Could the evolution of those systems go smoother if the
structures were opaque and we used accessors?  Probably, but you can't
say for sure, and it would still depend on the design of those APIs.

: I'll also check out the hints in the libtool manual - thanks for the
: reference!

Well, I checked again and they weren't *that* great, but anyways; there
are a couple of tips there...

  Lars J
-- 
(list->string '(#\l #\a #\r #\s #\a #\@ #\s #\i #\m #\. #\n #\o))