danielv at 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