Hi Anthony

Thanks for diving into this modules questions.
I have some questions of clarification and some notes.
In another mail I would like to give additional comments.

On Fri, 1 Mar 2002, Anthony Hannan wrote:

> Alright, my design has evolved already, here is version 2.
> 
>  Modules are organized in a multiple inheritance hierarchy.

A question for clarification: Why do you mention multiple
inheritance? Isn't it just an import list of other modules?

  
>  provides a name space that contains the names of its local objects
>  plus the local names in all inherited modules.  Names are searched in
>  topological sort order, ambiguous names raise an error (This search is
>  only required during compilation).
> 
> Instead of a module being a repository for objects it is just another
> object like a class whose main purpose is to provide a name space as
> described above.  Objects will instead be stored in image segments (see
> below).

Isn't this what we already have now?


>  Methods are compiled with respect to the current working module.

I consider it good to have the notion of 'working module'. That would be
the default place where the DeltaModules are created.


>  Selectors and globals are looked up in the modules name space. 
>  Ambiguities are presented to the user allowing him to choose a specific
>  inheritance path to disambiguate.  Selectors, like globals, are named
>  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.
Isn't this what Henrik has implemented in the recent alpha?

> Code can reference a named object that is not inherited by supplying the
> module path from an inherited module down to the name object.  When a
> name is added or deleted, all methods that use that name are rebound in
> case they are affected.

I do not understand this.


>  The current database transaction notes all loads and changes to the
>  image. Upon commit all changes are submitted to the active database. The
>  database will accept the commit if it does not conflict with other concurrent
>  changes. Multiple pending transactions and nested transactions could also be
>  implemented.
>  	The main database should contain all "approved" Squeak segments.  It
>  can be forked to allow different variants (like 'stable', 'alpha', and
>  'personal' for each user).  Transactions are not forgotten when commited,
>  they are kept around as database layers.  A layer can be copied and applied
>  to another database if it does not introduce inconsistencies.  And a layer can
>  be broken apart or merged into another layer.  A layer would be equivalent
>  to today's changesets.
Could you give some justification why you introduce Database transactions
and how do they relate to today's ChangeSets.

 
> An image segment is the same as today's image segment, it contains all
> objects reachables from a set of roots that are not reachable from
> anywhere else.  Pointers to objects outside the segment (outPointers)
> are converted to stubs when its segment or the target segment is
> unloaded.  These stubs reference root objects in other segments by
> segment id and root number.  So records of the Squeak database would be
> image segments with unique ids and foreign keys that reference other
> segments.

> 	Squeak would organize objects into segments automatically.  One scheme
> is put each module in a different segment, then objects that are
> reachable from more that one module would be added as a root to the
> segment whose module is the closest pointer to it.

Do you think this is feasible? At the moment 
   Module allInstances size 
gives 272.
 
> I like this design better from my first one because it separates name
> space functionality from database functionality.

Regards
Hannes Hirzel