Ordering of versions
cowwoc at bbs.darktech.org
Mon Nov 14 17:36:41 PST 2011
On 14/11/2011 8:19 PM, Neil Bartlett wrote:
> On Mon, Nov 14, 2011 at 6:20 PM, cowwoc<cowwoc at bbs.darktech.org> wrote:
>> On 14/11/2011 11:17 AM, Neil Bartlett [via jigsaw-dev] wrote:
>> Borrowing an analogy from Maven, you'd load the pom.xml file
>> separately from the main artifact. The pom.xml provides you with the
>> module metadata (version comparison in this case) and if you decide to
>> proceed to fetch the rest of the module.
> The analogy is bogus. Maven's POM -- like OSGi's manifest and Jigsaw's
> module-info.java -- is a declarative XML format, not an executable. We
> don't need to run any part of the module before we resolve the model,
> we only need to read the metadata and execute the comparison which
> exists inside the module system.
It doesn't matter whether it's a declarative XML format or an
executable. So long as the Comparator does not depend on any part of the
Module, it can be downloaded and executed independently just like the
>> 1) Treat the version comparator as a first-class citizen. There is one
>> comparator across all versions of a module and developers may replace it
>> as needed.
> How do I replace the comparator when I find it has a bug? Presumably
> until my new module with its new comparator can be installed, it must
> be compared against the current installed module using the current
> installed comparator. If the bug is as serious as, say, compareTo()
> returning +1 irrespective of the arguments, then the current module
> will always be considered higher than any replacement.
You're assuming that the Comparator is only replaced by the
Comparator from a higher version. I'm saying that the Comparator exists
outside the scope of any specific version. It applies module-wide. As
such, you can replace the Comparator without needing to evaluate the old
Comparator. It doesn't matter whether your version is "newer" or
"older", you just replace whatever is there.
>> 2) Each version has its own comparator. The first version that matches
>> the desired version-range gets used. In my opinion, the ability to
>> specify arbitrary version schemes is worth the risk of asymmetric
>> results similar to Objects.equals().
> Well I'm glad you see the risk, but I don't yet see the benefit. Is it
> really useful for different modules to be able to redefine ordering of
> versions? This is almost like each module wanting its own set of
> natural numbers.
Take a look at software projects in the world. Almost no two use
the same versioning scheme. The "benefit" is that we support the
de-facto standard which is to say these people have a good reason for
using different version schemes and there is no reason to believe we
know better than them. I consider version schemes to be the same as
code-formatting rules. They're highly subjective, there is no "right
answer" and enforcing a rigid "standard" is bound to piss many people off.
>> You could mandate that the Comparator operate deterministically,
>> and then cache the results.
> Please forgive the following diversion: a Russian friend once told me
> this joke that was popular during the old Soviet days. Stalin,
> Khrushchev and Brezhnev are riding a train together, and the train
> breaks down. Stalin goes and shoots the driver and engineer, but this
> doesn't solve the problem, the train doesn't move. Khrushchev offers
> the (new) driver and engineer a nice flat in the suburbs of Moscow,
> but this doesn't work either, and the train still doesn't move.
> Brezhnev stands up and declares, "I will fix this problem". He closes
> all the curtains in the train carriage, sits down and states "see, now
> we are moving".
> Mandating that a comparator must be deterministic is far less reliable
> than using pure declarations and controlling the comparison within the
> module system. Again, what's the benefit to balance this risk?
Heh. Good joke ;) Okay, so I guess we have to agree to disagree. I
completely see your point about the safety of a declarative model, but I
personally prefer the flexibility of an imperative model. I respect your
views on the matter.
More information about the jigsaw-dev