[reordered for convinience]
Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> wrote:
> danielv at netvision.net.il wrote:

> Have you read the previous postings where I explained the basic design?
Yes, but good idea. I just read them again, with my interest level
higher. Quite interesting.


> > OTGH, DMs are supposed to replace change sets, but when I make a change
> > set, it usually touches a few logical modules, not one. At least
> > eventually, it is the conjunction of deltas to several modules, not one.
> 
> Yes, to your project module, you may add multiple deltas, one for each
> module you "touch". This also automatically handles the equivalent of
> grouping and managing multiple change sets, without having to add another ad
> hoc mechanism for doing that.
Ah. So something that's born as a change-set (side effect of a lazy
afternoon's hacking) later evolves into a project module with several
delta modules, each holding the extensions the author believes should be
integrated next into various modules he may not be responsible for.
Right?

IIUC, I like this concept, it relates to how I'm working now on the RB
module.

BTW, would these DM be submodules or imports? can DMs be submodules?
(I'm still trying to pin those concepts down...)

> > On one hand, they represent the same thing as a Module, except stored as
> > deltas from a specific module.
> > OTOH, DMs can be extensions, but Modules can't. ?!
> A Module can't be an extension since it isn't an extension of something. A
> Delta is by definition an extension from a base (module).
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).

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. So IMHO, we should have
module that include extensions of classes, even if no module is
reference in which the class is defined. Maybe there's a better
solution. 

I don't know if this is what you mean by the half implied reference to
DeltaClasses in the DeltaModule comment...

> 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?
 
> Having DMs, I've decided to leave change sets untouched. So people can
> continue using them like now, but a major point in this discussion has been
> the weaknesses of change sets, which is what DMs are meant to remedy.
Well, good, that's what wasn't clear.
 
> > What do you mean when you say your are/will be built for a
> > "internet-distributed, collaborative open-source project"?
> 
> Well, "delivering runtime (end-user) pieces of software" represents a very
> small fraction of what Squeak is used for. 
Agreed totally.

> There are numerous other aspects
> that we need to deal with, as have been stated by others already. Handling
> contributions, bug fixes, changes to system classes, handling conflicts,
> shared repositories, and allowing multiple uncoordinated projects to proceed
> independently are some such things.
I like what I understand from your proposals so far.

So far the idea of "no class extensions unless you specify baseline
module and version" seems a bit tighter than my comfort level, otherwise
very interesting.
 
> Henrik