Andrew P. Black wrote:

> Perhaps its a bit late to poke my oar in here, but I agree too.  In
> addition to modules, we need a way of connecting together modules to
> make systems.  That is, we need a module interconnection notation,
> which we can use to express what is sometimes called a 'system
> model'.  This model is where the fact that we want to build a system
> containing a particular version of the morphic ellipse class goes --
> not in a module that uses an Ellipse morph.

There is some support for what I think you refer to. The "module
interconnections" are ModuleReferences. What you mention would be done by
creating new "contentless" modules that you hook up to certain existing
modules. E.g. you would have a ModuleReference specifying BasicMorphs v1.1
or whatever--and there would be no reference to a specific module inside
your code.

Then there are also ModuleParameters (a subclass of ModuleReference) so that
you can allow "users" of a module specify what actual module it should be
binding to. 

For example, a Diagrams module might have a module parameter named Morphs,
so that code in the module says Morphs Ellipse, but Diagrams doesn't specify
what module should provide the implementation of Ellipse. You would then
have to do that when you hook up the Diagrams module.

Göran and I spoke about this at oopsla, and concluded that there should be a
special kind of ModuleReference, much like an alias or a symlink in a file
system, to be used for building what you call "system models".

One example use for this would be to create smaller images (headless, MVC
only, etc.) by creating a module (or many) that aliases the existing modules
that you want.

However, along the principle of first things first, I haven't completed
these things. I figured people could start using the basic things first, and
then take on such things when they need them.

> I think that perhaps one solution to this is a tool that builds the
> configuration for us.  The obvious thing is to do name matching: if a
> module uses an undefined global (like Ellipse), the tool would simply
> search all of the other modules hat it knows about -- maybe all of
> those in a web-based repository -- and find the places that define
> something called Ellipse (which might or might not be a class, given
> Smalltalk's lack of type declarations).  If there is more than one,
> it might ask me which to choose, or it might apply some heuristics.

This code is already in there as well, although as I just replied (in
another thread I think) the automatic declaration will never be smart enough
to get it right.

> Which is why I think that it is really important that the tool
> generate an explicit system model that binds all of the otherwise
> unbound names, and that WE CAN BROWSE the model that it outputs.

Absolutely. This is the now famous list of neighborModules, now playing in a
ModuleExplorer near you. If it is empty (as it is for most modules since the
image awaits being modularized) then the name lookup falls back on searching
the whole image for matches--which works for now since there are only unique
class names in there still.

Henrik