3

Sometimes, 3rd party libraries cause havoc when they change their interface. In some languages, it even happens on the language level.

Is it possible to write our code in a way that will prevent it?

For instance, I can think of one way - writing your own wrapper functions.
In that way, the changes will be localized to one function. But then again, it creates a large overhead.

Do you have any ideas?

Andrey Rubshtein
  • 20,795
  • 11
  • 69
  • 104
  • 1
    This is an interesting philosophical question, but has no practical answer other than "experience" and "luck". Very often schemes promoted as preventing this problem do exactly the opposite. (I'm not voting to close but I suspect this thread will be closed by the time I finish this comment.) ((Added: OK I was wrong -- shows you how hard it is to predict the future.)) – Hot Licks Dec 20 '11 at 23:17
  • I gave an example of one practical idea. I think there might be more. – Andrey Rubshtein Dec 20 '11 at 23:22

2 Answers2

3

Basically, you include some sort of version mechanism (generally with more granularity than just low/high version limits), and you try to keep interfaces separate and "orthogonal". But a lot depends on which side of the interface you're on. On the "consumer" side you can only do so much.

IBM System/38 and it's descendents managed to maintain compatibility such that programs compiled on the first release could still be run, without recompiling, 30 years later (and through two revisions of the machine instruction set, the second quite drastic). But that is an unusual case of pretty good (though not perfect) original design, combined with fairly strong motivation (large banks that spend a lot of $$ on the systems) to maintain compatibility.

At the personal computer level many system designers don't really care, since incompatibility sells more software upgrades, which in turn sells more hardware.

Hot Licks
  • 47,103
  • 17
  • 93
  • 151
2

Apple suggests to its developers the idea that your code can check for versions; then you can update your code as needed when a version changes. Here's a link to their more thorough discussion:

Mac OS X Developer Release Note

Basically, they provide markers that can be used in header files to indicate the max version in which a component is meant to be used or is known to work.

leanne
  • 7,940
  • 48
  • 77
  • Of course, probably fewer than 50% of iPhone apps written against iOS 4 run on iOS 5 phones. Apple made multiple non-upward-compatible/non-downward-compatible changes, without even a partial version in-between that tolerates both. So Apple's advice should be taken with a grain of salt. – Hot Licks Dec 21 '11 at 01:24
  • 1
    Regardless of whether Apple followed their own advice, version-checking is still another valid idea for backward compatibility - and one you yourself endorse in your own answer on this thread. – leanne Dec 21 '11 at 17:16
  • Yeah, but it's rarely done well, or with adequate granularity. Nokia did a halfway decent job, with their largely defunct Symbian products. – Hot Licks Dec 21 '11 at 19:57