Generalized Object Modules Design

Anthony Hannan ajh18 at cornell.edu
Mon Mar 4 18:38:35 UTC 2002


I'm sorry that my module design suggestion was not thoroughly thought
out, I was just thinking out loud (I'll be more thoughful next time). 
I'm not trying to re-invent modules, I'm just trying to come up with a
high-level design that I'm happy with, then I would look at the
differences and suggest changes to the current module implementation.

I like the current module design except for a couple of things:
 1. Modules do not store arbitrary objects - Meaning another framework
will be needed for components, eg. Morphic projects.
 2. Selectors are not first-class objects in modules - We cannot
automatically determine dependent modules based on selectors used, only
globals used.  If module A sends a message #foo and module B implements
#foo then B should be a dependent of A.  You might say that since the
receiver is loaded when the message is sent, its class will be loaded
also with all its methods.  But not all its methods may be loaded.  #foo
could be sitting in the deltaModule of another module C that is not a
dependent of A.  The programmer when writing the send to #foo has to
make sure the target method(s) are included as dependents, manually.

Maybe it is too hard to include the above features into to a module
design and are better left out.  But I'm going to continue exploring
design ideas until I find one I like better or I convince myself that
the current design is the best.

Note that I really like the idea of default methods for selectors making
them automatically reusable to any class that implements the core
messages they send (see "Behavior design options" thread), so I will be
exploring module design ideas that are conducive to this.

Cheers,
Anthony



More information about the Squeak-dev mailing list