[ENH][Modules] Another version

Henrik Gedenryd Henrik.Gedenryd at lucs.lu.se
Thu Sep 20 13:12:09 UTC 2001


danielv at netvision.net.il wrote:

> Yup, I read what there is about the DeltaModules. I'm a bit confused, it
> seems like they're supposed to be many things at once, this looks
> confusing to me, maybe I don't have the right glasses yet.

I won't blame you for not being able to infer everything correctly from a
class comment :-) I think things will be clearer once the features are
implemented.

DeltaModules are not really trying to be several things, they are one thing
that replaces several ad hoc solutions. In comparison, Modules enable us to
remove a number of features that have been placed in the system to
compensate for the lack of means for structuring the image. E.g. the
SystemOrganizer (to structure classes) and class pools (to structure
semi-global variables).

Similarly, by extending modules with DMs we can have one construct to do
things that are done by several different solutions now: change sets, the
package browser, isolated projects, conflict management, etc. So the problem
is really that there are a number of ad hoc solutions in there now that
aren't integrated with each other. Now we can have a single concept instead
all of these.

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

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

If you look at the code I posted there is an example showing how it is
supposed to work.

> I think someone (Allen) had a point when they said that change sets
> serve a different purpose than modules.

DMs do have a different purpose than regular modules; they manage
modifications to existing modules.

>I think young change sets group
> changes that are close in time and author (like updates). As time
> passes, I refactor things into more logical, permanent groups, like a
> logically coherent changeset I'd post to the list or to divisions like
> categories/modules.

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.

> [abstract comparison of ModSqueak and Henrik's work]
> Please *do* tell us more about the differences, because:
> A. I'm (we're?) curious.

Yes we are, but I don't think it is my task to explain or document someone
else's work.

> B. If we understand what it's trying to do, there's more chance we'll
> use it (negative example - Environments)

Have you read the previous postings where I explained the basic design?

> C. We might have good ideas.
> I'm you don't need to get into a flamewar, you followed your ideas, they
> followed theirs.

I can't take all the credit. I have listened to and taken up ideas from many
people here. I have also used Dan's Environments code a lot.

And I think it is a mistake to restrict ourselves to looking at other
Smalltalks. Smalltalk hasn't exactly made itself known for its good
modularity solutions. I have looked at e.g. the work of Niklaus Wirth and
David Parnas (the modularity gurus), Goguen (parameterized modules), and
others.

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

Henrik






More information about the Squeak-dev mailing list