"Andrew P. Black" wrote:


> Since Modules can contain sub-modules, and some of those sub-Modules
> can be DeltaModules, then it seems that in any case you have not
> achieved anything with this restriction.  I just put my "loose
> methods" (like String >> asUrl) into a DeltaModule inside my Module,
> and the unsuspecting user who imports my module is still surprised
> that it "damages" other classes like String, or Form, or whatever.

That is not a bug, it's a feature ;-)

But, thinking about it, you touch a valid point here. In my
understanding a module always describes a closed, self contained unit
with globals  and classes in a name space. Delta Modules describe deltas
to one of these units.
But, and I had made that point earlier in a discussion, this clean and
simple mechanism(?) is broken by having modules be also the unit for
packaging arbitrary combinations of other modules and delta modules.

Hmm, again, confused...

> I think that we should indeed do what Henrik writes on the Wiki:
> build a "minimal and yet powerful semantic model for a Squeak Modules
> system".  I don't think that this policy separation between defining
> new and modifying old need be part of that model.  I think that this

I still would think that a delta module is a mechanism. I only hope this
thread doesn't end up with us throwing dictionaries at each other ;-)

Michael

-- 
 "Knowledge is the only resource on earth that multiplies when shared." 
    +------------------------------------------------------------+
    | Michael Rueger    m.rueger at acm.org      ++1 (310) 937 7196 |
    +------------------------------------------------------------+