Allen wrote:
 > The only logic I don't follow is why you think the module reference needs
 > to be physically contained in the class or CompiledMethod object.

I did not think it was all that unusual to have the class know its own
environment- I don't see this as a problem.  The CompiledMethod idea is a
non-starter, though- Squeak's compiler does not allow me to create a subclass
of CompiledMethod which would have such an instance variable, so other
mechanisms are needed... so, yes, looks like we'll have to use some kind of
indirect referencing to keep track of this.

[alternate proposal skipped]

 > Another advantage of such separation is that, in theory, you could define
 > multiple modular views upon the same image.  This might be quite
 > interesting during the phase when people are experimenting with alternative
 > ways to modularize the system.

That's the important property- I have a strong feeling that it will be very
valuable to be able to readily change these schemes- and this kind of goes
back to the Fear factor you mentioned earlier.  If we can use existing,
reliable tools to keep things propped up for a while longer, then we will have
more freedom to experiment... If we are able to discard these experiments
without fear, we will be in pretty good shape.

 > Finally, this type of independent representation of the structure of the
 > image is essentially the basis of the "semantic model" used by ModSqueak,
 > Team/V, and other similar systems.  Once you take a little step in that
 > direction, its easy to take additional steps and do a lot of neat things.

Sure- my proposal is based somewhat on the observations I've had in Oasis
where I did initially start out with a passive model as a sort of buffer to be
used to load code without actually having it installed in my image.  So, in
the early days I did all the code analysis over these inert models.  But over
time, I realized that in order to do more, I would like to have those models
become active- and that, if I really did understand and control just when
messages would be sent to the classes in a module, then I could also go ahead
and use live class objects in the same role as the inert ones.  So, that is
what I do now- you can actually do qute a lot with a model where the only
difference between an inert specification and an active class model is whether
you've sent any messages to it or not to have it start instantiating its
instances.

But I do believe there is a definite role for a specification layer working in
parrallel- for instance, right now I can pour all kinds of code into an
OasisModule, code that might otherwise represent several modules.  Any time
you do this, you run the risk of having them conflict with each other- just as
you do on a larger scale with an entire image's worth of classes.  So, while
OasisModules do provide a nice partitioning of active class space, there is
still a role for a specification space model where those conflicts can be more
readily managed ( I still have my inert model, and could use it in this
role ).  In other cases, where the code is poured into different OasisModules
which are then later connected, there are other mechanisms at the active class
level that can be used to resolve these conflicts.  But those techniques are
not going to be accessible in the near term.  So, that leaves us back to
relying on spec space to take care of all of them.

 > Allen