Ordering of versions

[cowwoc]

Hey Neil,

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:
>> [snip]
>>      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 
pom.xml file.

>> 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.

Gili