RangeDependencies
From APIDesign
(→Too Much Flexibility will Kill You!) |
|||
| Line 3: | Line 3: | ||
It [[dependencies|has already been discussed]] that dependency needs some lower bound (the moment when the needed [[API]] is first introduced) and also some higher bound (as incompatible changes are so often). How do we formalize it? Well, let's use some mathematics and describe dependencies as [[interval]]! As a result a dependency on any compatible version 1.4.3 and later, would be written as <math>some.library \in [ 1.4.3, 2.0)</math>. | It [[dependencies|has already been discussed]] that dependency needs some lower bound (the moment when the needed [[API]] is first introduced) and also some higher bound (as incompatible changes are so often). How do we formalize it? Well, let's use some mathematics and describe dependencies as [[interval]]! As a result a dependency on any compatible version 1.4.3 and later, would be written as <math>some.library \in [ 1.4.3, 2.0)</math>. | ||
| - | This looks like a very good solution. It is also very [[Rationalism|rationalistic]]. It is reusing knowledge gained by mathematics in past and thus it cannot be wrong! Moreover it is ''general'' enough - one can use the same notation to express [[dependencies|equality dependency]] by writing <math>some.library \in [1.4.3, 1.4.3]</math>. And also it is ''flexible'' as one can also depend on a smaller range of versions <math>some.library \in [1.4.3, 1.5)</math>. Last, but not least this solution also supports some level of [[cluelessness]] as it builds on something every programmer must have | + | This looks like a very good solution. It is also very [[Rationalism|rationalistic]]. It is reusing knowledge gained by mathematics in past and thus it cannot be wrong! Moreover it is ''general'' enough - one can use the same notation to express [[dependencies|equality dependency]] by writing <math>some.library \in [1.4.3, 1.4.3]</math>. And also it is ''flexible'' as one can also depend on a smaller range of versions <math>some.library \in [1.4.3, 1.5)</math>. Last, but not least this solution also supports some level of [[cluelessness]] as it builds on something every programmer must have heart of during own school days. |
No wonder that everyone one who wants to be seen as providing ''well designed'', ''deeply thought out'', ''powerful'' and ''theoretically backed'' solution will choose [[interval]]s. This is probably the reason why [[OSGi]] decided to use this kind of dependencies. | No wonder that everyone one who wants to be seen as providing ''well designed'', ''deeply thought out'', ''powerful'' and ''theoretically backed'' solution will choose [[interval]]s. This is probably the reason why [[OSGi]] decided to use this kind of dependencies. | ||
Revision as of 19:55, 18 October 2009
Dependencies are important part of every Module system. Dependencies are here to abstract the complex relationship between a module and environment it needs for its own execution, compilation, linkage, etc. Dependencies are always a simplification of the real requirements, but that does not stop people from inventing new and new ways how to specify them more precisely.
It has already been discussed that dependency needs some lower bound (the moment when the needed API is first introduced) and also some higher bound (as incompatible changes are so often). How do we formalize it? Well, let's use some mathematics and describe dependencies as interval! As a result a dependency on any compatible version 1.4.3 and later, would be written as 
.
This looks like a very good solution. It is also very rationalistic. It is reusing knowledge gained by mathematics in past and thus it cannot be wrong! Moreover it is general enough - one can use the same notation to express equality dependency by writing ![some.library \in [1.4.3, 1.4.3]](/images/math/4/3/9/4390bf48ac1e6082ecba340f857987d7.png)
. And also it is flexible as one can also depend on a smaller range of versions 
. Last, but not least this solution also supports some level of cluelessness as it builds on something every programmer must have heart of during own school days.
No wonder that everyone one who wants to be seen as providing well designed, deeply thought out, powerful and theoretically backed solution will choose intervals. This is probably the reason why OSGi decided to use this kind of dependencies.
Too Much Flexibility will Kill You!
Although it may seem flexible, improperly using RangeDependencies may lead to system that is too complex and almost no longer manageable. What traditionally happens only when people release incompatible versions (due to TransitivityOfIncompatibleChange) can suddenly happen in regular situations.
The proof claiming that managing module dependencies is NP-Complete operates with three types of modules:
- Mi which is present in two incompatible versions
- Fj which is present in three compatible versions
- a single module T
The claim is made that finding whether module T can be enabled is NP-Complete.
One of the most profound critiques however argues that it is wrong if three compatible versions of module Fj depend on incompatible versions of some other modules. This is valid observation, yet one can easily address it using RangeDependencies!
- instead of two incompatible versions of Mi define two compatible versions:
and 
- use strict range for dependencies of Fj, so
depends on ![M^i \in [1.1, 1.1]](/images/math/b/9/5/b95887a40be73becccf2143f3364e204.png)
or 
depends on ![M^i \in [1.2, 1.2]](/images/math/b/6/6/b66f740e855d9bbe2a1c3cd1118aca9f.png)
- single module T continue to depend on classical range of
This scenario describes accepted practices of DistributedDevelopment. Imagine, there is one team providing various versions of module Mi. This team does its best to keep BackwardCompatibility. It is using versioning in the traditional way to denote compatible versions - e.g. the first major number stays the same, the second minor one is incremented with each new, compatible version.
Yet there is some other distant team producing module(s) Fj and this team (or its quality department) is afraid of signing blank checks and trusting the M-team to produce compatible versions. Thus they use restricted RangeDependency to require just subset of the versions (only those known during testing).
This is all that needs to happen. No incompatibilities, just a simple use of RangeDependencies and we are now facing an NP-Complete problem. This probably explains why there is 3SAT solver behind Equinox. Finding the right setup of modules depending on each other with RangeDependencies can be really hard. NP-Completely hard.
Follow
