2014/7/7 3:43 -0700, [email protected]: > Great document! Thanks! Glad you like it.
> Overall this set of requirements is almost a perfect > match with the requirements we derived for our own module system, which > makes me feel that it is hopeful that (a) this project has found the > right course and (b) we also have found the right course. :-) Or else we're all on the wrong course! > I also agree with all of the non-requirements, with a few small caveats > given below. > > Firstly, in many places the document refers to versions of modules, > including specifying that the module system cannot support more than one > version of a given module. But I believe this is somewhat misleading. > If you think about what this really means, you have to answer the > question: What does it mean to be a different version of a module? Or, > at what point do two versions of one module really conceptually become > two separate modules? When is the Ship of Theseus no longer the Ship of Theseus? > ... > > My intent with this example isn't to start talking about implementation > though - it's just to use a real-world example to illustrate the idea > that "multiple versions" is a sort of human concept that doesn't really > have an equivalent that can be mapped concisely to specification - > something that didn't really click for me right away, retrospective > obviousness notwithstanding. The specification as given here does seem > to match my experience, if you read between the lines a little (and > deduce that a module must be identified uniquely within a configuration > (if not globally), and that the spec-defined module version can not be a > direct part of that identification), but I think (if not here than in > the final specification) it will be worth having a non-normative section > that discusses the idea versus the technical reality of multiple version > "support", and that not supporting multiple versions as a first-order > concept doesn't really mean you *can't have* multiple versions, per se; > it just means that the module version constraint mechanism cannot be > used in this way. This will at the least have a big impact on community > perception, as the naive user might be somewhat affronted by what they > view as a key feature not being directly provided (even if it is > technically still possible - perhaps even easy - to accomplish in > practice, though perhaps in a slightly less obvious way). I agree that giving guidance here will be important. > Secondly, I have a minor concern about this statement: > > "Enforced version constraints — The process of configuring a set of > modules must, in all phases, satisfy every version constraint of every > module except for constraints that are overridden, in which case the > overriding constraint must be satisfied." > > I note that the definition of phases was even more well-hidden compared > to the previous incarnation of the requirements doc, but it can be > deduced from the "Upgradeable modules" item to be the set of compile > time, build time, and run time. It wasn't my intent to hide the phases concept or definitions, but I see how the document can read that way. I'll fix that in the next draft. > My question, however, relates to run time. I don't think one has to get > too far into speculating about implementation to deduce that the only > form that this constraint can take (and still be a constraint) is > throwing an exception of some sort when a non-satisfying module is > loaded. My gut feeling is that once you get to run time, it might be > more damaging to enforce this constraint than to let it slide (though > maybe with a warning of some kind, if possible). ... The "Overrideable version information" requirement allows both developers and deployers to fix broken version strings or constraints. Whether the run-time system should force you to use that mechanism when a constraint is violated, or just issue a helpful warning message, is a design decision we can make further down the line. - Mark
