[NTLUG:Discuss] Upgrade breaks things

[kbrannen@gte.net]

brian at pongonova.net wrote:
> On Fri, Apr 12, 2002 at 03:07:08PM -0500, Steve Baker wrote:
> 
>>  3) Some libraries require a *structure* to be passed as a parameter
>>     to some library call.  If at some future time, a new variable
>>     has to be added into that structure, it's almost impossible to
>>     do it without breaking reverse compatibility.  This problem
>>     is especially acute for C++ applications that actually make
>>     use of a class-based interface.
> 
> 
> If the developer knows what he/she is doing, this should *never* be a reason for
> backward-compatibility issues.  That's the whole point of specifying a struct or
> class pointer:  You should be able to modify the *internal* structure of the
> struct/class, along with related implementation details, without ever breaking
> older applications which depend upon the previous interface.
> 
> What often happens is that a developer without a clue (or a clue that is just
> flat-out wrong) will pass a struct/class by value (which will obviously break older
> apps during compilation since the binary "footprint" is different), or the
> developer will modify something in the implementation which breaks
> backwards-compatibility (usually evident as a segfault or other run-time error).

Well, I've always thought I've had a least a small clue, but I can't guarantee 
there "should *never* be a reason for backward-compatibility issues".  Perhaps 
you can guide the rest of us here.  (that is slightly tongue-in-cheek, but I 
do mean that seriously)  Please consider Steve's reply as he has touched on 
some good examples.  Also remember that a good project architect should try to 
keep the design consistent and as simple as possible.  These other constraints 
are the catalyst for making incompatible changes at times.

BTW, if you want to see a place where people have gone too far to avoid 
incompatibility issues, IMHO, look at the X11 structs.  Many of them have a 
member like:

   XExtData *ext_data; /* hook for extension to hang data */

which looks like:

   typedef struct _XExtData {
         int number;             /* number returned by XRegisterExtension */
         struct _XExtData *next; /* next item on list of data for structure */
         int (*free_private)();  /* called to free private storage */
         XPointer private_data;  /* data private to this extension. */
   } XExtData;

The idea being the original struct can stay the same, then when new needs come 
along, additional structs can be chained onto it.  Conceptually interesting, 
but I view it as so hard to use, I'd just as soon they just add the new fields 
on the end of the struct and note it in the release notes, and tell us to 
recompile everything (which works well in Open Source).  But then I don't have 
to support a whole community either, so maybe I don't have a clue. :-)

I could see someone saying:  Compatibility, Consistency, Simplicity--pick 2. 
(to borrow from an old saying :-)

Kevin

p.s. Steve, I really like the phrase "20-20 foresight". :-)