Generalized Object Modules Design

Henrik Gedenryd h.gedenryd at open.ac.uk
Mon Mar 4 11:30:43 UTC 2002


Anthony Hannan wrote:

> Below is a module design that varies slightly from the current one but

Yes. *VERY* slightly. Please please *please* cooperate instead of
reinventing the wheel!

> allows storage of arbitrary objects

Hmm. This usually isn't considered as modules but components. The
established cs meaning of modules is that they define static pieces of
program definitions (as in source code). Live, running (dynamic) things are
components. These are different things. Very different things.

> and has a different dependency
> structure. 
> Modules are organized in a multiple inheritance hierarchy.  Each module
> provides a name space that contains the names of its local root objects
> plus the root names of all inherited modules.  Names are searched in
> topological sort order, ambiguous names raise an error (This search is
> only required during compiling or module loading).
> Every object belongs to one and only one module.

This sounds very much like what is there already. I can 100% guarantee (it's
graph theory) that your scheme either can do the same as the current one, or
yours does less because there is some limitation in there.

Looking closer, it seems like your scheme lacks the ability to specify
whether names should be inherited from dependent modules or not. That is
probably what you mean by MI, and it would indeed be such a limitation.
Effectively, your scheme would inherit the well-known problems of MI, which
have been recently discussed in a different thread.

> When saved to disk,
> an object pointer that crosses a module boundary is converted to a disk
> pointer containing a relative path name, and the referenced object
> becomes a root of its module if it is not already.  The relative path to
> an inherited object is equal to its root name (disambiguated if
> necessary) allowing overriding.  The relative path to an object not
> inherited is equal to its top-down module path from the closest common
> parent.

This seems just like the existing plan to store the current modules as image
segments. Alexandre Bergel has been working on this for a while already.

But have you thought about the problems of maniaging the references to the
sources/changes files?

Don't you think it would be better to add to the existing scheme, or
cooperate on the image segments part, for instance, than to start all over
again?

> an object pointer that crosses a module boundary is converted to a disk
> pointer containing a relative path name

This seems like a more brittle solution than the one described here (scroll
to "Steps to compact files and fast loading with image segments"):

http://minnow.cc.gatech.edu/squeak/2066

This method asks the module at the end of loading to use its normal name
lookup scheme to find the definition for a name, instead of storing a
relative path upon save, which may be wrong or changed by the time it is
brought in. So the references of the external definitions in the new image
are bound with respect to the contents of the new image, not the old one.

And by the way, how do you know when "an object crosses the module
boundary"? In the current scheme this is easy to tell because it doesn't mix
the concepts of modules and components.

> Methods are compiled with respect to their owning module (remember
> every object belongs to a single module).  Selectors and globals are
> looked up in the modules name space.

As it works already.

> Ambiguities are presented to the
> user allowing him to choose a specific inheritance path to disambiguate.

As discussed in another thread, this method is too brittle, as it would have
to have this info given each time e.g. a method needs recompilation such as
when the format of the class or a superclass changes.

> Selectors, like globals, are root objects of modules.  Instead of
> storing selectors in a global symbol table, they are stored in modules.
> The same selector name in two different modules will be treated as
> different selectors, compiling will bind the method header and message
> sends to one or the other.

Okidok, selector namespaces have been discussed before. However,

If I define new on the class side for some class in my module, it will
effectively become new(2). Then if I say "Object new" in this module, then
this new will also become new(2) and not the new(1) that Object can respond
to, so it will fail. Or even more so, if the code is something like
"theActualClass new", as in "anObject species new" or something, referrin to
a variable, not explicitly to a class. Then which selector should be used?

Henrik




More information about the Squeak-dev mailing list