Talk:BackwardCompatibility

From APIDesign

Current revision

Regarding BackwardCompatibility and, in particular, Functional Compatibility, you suggest that the output must be "the same result", which implies that only deterministic functions can achieve functional compatibility.

-- dmbarbour?

This is a little bit too mathematical point of view. I was only using common sense. In particular, if the behaviour was non-deterministic in previous version, then the behaviour shall be still non-deterministic. That is the same result I had in mind. Mathematician would say that the probability distribution remains unchanged. OK?

--JaroslavTulach 05:52, 28 August 2009 (UTC)

It seems to me that Functional Compatibility would be met with much looser restrictions: that the output must not further restrict any pre-conditions, and must continue to meet all post-conditions, specified for the function. I.e the "same" result isn't required, but a result that remains within functional specifications is required. This is especially useful when describing updates to, say, constraint programming paradigms and situations where non-determinism is involved or allowed.

-- dmbarbour?

First of all same result means, same output with the same arguments. API can definitely evolve to accept more inputs. Doing that correctly is in fact the art of Evolving the API Universe correctly.

Your comment seems to exhibit the common contention between rationalism and empiricism. It would be right, correct and beautiful if the compatibility was specified by contra-variance in preconditions and co-variance in post-conditions. The problem in real world however is that pre or post conditions are usually unspecified. I come from a project where I have to convince hundred programmers to keep BackwardCompatibility. In such environment one has to be over-demanding. I have to ask for more to get at least a bit of compatibility. Thus I define the functional compatibility so strictly. I use the Amoeba Model to claim that the actual behaviour is more important than the intended one. I say that the way things work (even if buggy) is more important than any specification. This is reasonable approach from one point: It puts all the blame on the author of the API. This is not really fair, but it seems to be the only practical way to get at least a bit of BackwardCompatibility.

--JaroslavTulach 05:52, 28 August 2009 (UTC)

Achieving the same result should be another level above functional compatibility. Or perhaps the above could be a lower level, like 'interface' compatibility. But coupling at the level of 'functional compatibility' would then be a clearer no-no: it means the project is coupled to the implementation rather than the interface.

-- dmbarbour?

I also suggest to Code Against Interfaces, Not Implementations, however the truth is that the implementation always leaks. Users of the API do not start by reading a specification. They are quite clueless. They prototype and if it works, they are done. What happens in next version is behind their horizon. So I think that in practise almost every project gets tight to particular implementation of an API.

As I rationalistic person I would find it very good if your approach could be merged with the whole over present cluelessness. I just don't see a way to enforce that. Thus for now I'll stick with over-demanding.

--JaroslavTulach 05:52, 28 August 2009 (UTC)

cdawg said ...