'. '

Talk:BackwardCompatibility

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(New page: Regarding BackwardCompatibility and, in particular, Functional Compatibility, you suggest that the output must be "the '''same''' result", which implies that only deterministic functio...)
Line 1: Line 1:
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.
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.
-
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.
+
-- [http://lambda-the-ultimate.org/node/3588#comment-50889 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?
 +
 
 +
--[[User:JaroslavTulach|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.
 +
 
 +
-- [http://lambda-the-ultimate.org/node/3588#comment-50889 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 [[cluelessness|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]].
 +
 
 +
--[[User:JaroslavTulach|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.
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.
 +
 +
-- [http://lambda-the-ultimate.org/node/3588#comment-50889 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 [[cluelessness|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.
 +
 +
--[[User:JaroslavTulach|JaroslavTulach]] 05:52, 28 August 2009 (UTC)

Revision as of 05:52, 28 August 2009

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)

Personal tools
buy