danielv@netvision.net.il wrote:
BTW, would these DM be submodules or imports? can DMs be submodules? (I'm still trying to pin those concepts down...)
I think they should be submodules of your project, as they are "part" of it.
In your String>>asUrl example - String is probably a far more long-lived concept than the BasicTextHandling-V.26 module. Would I have to extend a specific Module and version? this seems to flow from your definitions, but practically speaking, asUrl probably doesn't depend on many features of a specific module version, and it would mighty tedious maintenance to be constantly rereleasing the same code with updates requirements.
Might be a good idea to have looser definitions of requirements - like BasicTextHandling >= V.26 (this is done in the Debian package system, at least, I don't know about ENVY/Team).
From the previous discussion here, this seems like an unsolved problem in
version management. We may consider specifying version dependencies with varying precision, so that "1" will be any version 1.x, "1.1" any 1.1x, 1.1014 just that, and version unspecified will be any version.
However, note that String should change very slowly. Practically never.
But specifically in the case of extending String - This class is so long lived, so basic, that probably even just specifying the name of the module relative to which extension must be defined, is limiting it's use unneccessarily.
I don't see why it would be a problem to associate String changes with the module that String is in? Surely which module it is in shouldn't change much either? Not having this info would make conflict resolution much uglier.
If you look at the code I posted there is an example showing how it is supposed to work.
Sorry, I wasn't able to resolve that reference... what message, what code do you mean?
In the Module explorer that opens when you load the code, (first do all the conversions, then) select a module, e.g. #(Squeak MVC), and execute "self collectUpstreamMethodsOutside: self" in the lower pane. Then look at the new submodule(s). Now, all outside methods referring to MVC globals are collected into MVC DeltaModules--currently 72 of them, which tells us something!
Henrik