Short module/delta module intro! Re: A Tool for managing modules

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Mon Feb 4 08:43:15 UTC 2002


Henrik Gedenryd <h.gedenryd at open.ac.uk> wrote:
> Ned Konz wrote:
[SNIP]
> >>> But this is the strange thing: the Package Browser shows that I've added
> >>> the new method to the class in question (this is a one-method extension
> >>> to MessageSend).
> >>> 
> >>> It's in a module called
> >>> #(People NedKonz Connectors 'Squeak Language Core Objects delta')
> >> 
> >> Strange name for a module, but anyway I will try to fix that.
> 
> This is a DeltaModule, its name is automatically generated from who defines
> it and what base module it affects.
> 
> > I didn't name it. The import did. I tried to import to #(People NedKonz
> > Connectors) and it put my extensions in modules with names like that.
> 
> Exactly. The importer recognizes class/module extensions automagically.
> 
> >>> How am I supposed to use the system if I can't extend existing classes?
> 
> But you just did!

There is probably a good description of the Modules system on the Swiki,
and even though I promised Stephane to write something up, I am not sure
if I will be able to do that "in time". Anyway, without having looked at
the latest of this stuff my perception of these things as of OOPSLA (I
may be simplifying to get the points through):

Modules can be viewed as standalone collections of classes. They live in
a namespace of their own and if they reference (references them,
actually it's about globals in general, not only classes of course)
other classe in other modules, those modules become so called "external
modules" to the module. It's more or less like an "import" I guess. So a
module "depends" on other modules in this way.

So far so good - it is quite logical that a module has a namespace of
it's own, it also seems quite logical that it needs to, in order to be a
real module - otherwise it would be able to clash with other classes
having the same names in other modules. Now it only needs to make sure
that the "external modules" don't have clashing lasses (globals).

The ideas that a module only contains standalone classes (and no loose
class extensions, see below) they are by definition loadable without
conflict. It's just a bunch of classes that can't possible affect
anything.

Ok, here comes the tricky - but I would also like to say - the neat
thing: a DeltaModule

A delta module represents the changes that a module "needs to apply" to
other modules in order to "be happy". The typical example is adding a
method to a class in another module. Since a "pure" module can only
contain "standalone classes" it will have to have delta modules (as
children) for this.

A single delta module captures all changes that one module wants to
apply to a single other module. So if our module wants to add two
methods to two different classes in ONE other module, we get ONE delta
module. But if those methods where to be placed in classes from TWO
other modules we would get two delta modules - one for each other module
that we need to apply changes to.

So if I find a module with 33 delta modules in it I get scared. :-) I
can also tell that this module depends on 33 other modules in a non
trivial way (trivial being a simple client of those other modules). If
it had 3 delta modules I would be happier, and if it had none I would be
real happy.

Well, over and out, perhaps someone got a bit wiser... :-)

regards, Göran
PS.
<CSOTD>"Newbie tips:"
"Class A inherited a method that it should not be able to do? Stop it by
implementing the method as:"
self shouldNotImplement
"The above is normally a screaming alert of bad inheritance (but it
doesn't have to be).
We have 40 of these in the image. Hmmm. Make sure that A really should
inherit from B..."

"Class A implemented a method that it would like it's subclasses to
implement, implement as:"
self subclassResponsibility 
</CSOTD>
DS



More information about the Squeak-dev mailing list