[Modules] Name space semantics was: Re: Some of my thoughts

Stephen Pair spair at advantive.com
Thu Aug 16 20:34:37 UTC 2001


(one addition point)

> > The difference is that "'add:' asSymbol" would always yield 
> the same 
> > object no matter which module you are in.
> 
> This could be done in either approach. Since you do have to 
> modify the compiler to generate the prefix bytes you could 
> equally well define that only a compiler lookup will go 
> through the local selector name space.

True, but if you have a selector in hand, you will eventually come
across situations where you need to determine in which module that
symbol was defined.  Searching through all modules in the system and
inspecting the local symbol tables would not be very efficient.

On the other hand, adding a module instance variable to the selector
(logically speaking) that references the module in which it was defined
has the benefit of being able to quickly lookup the module, while at the
same time not require any additional symbol tables.  The compiler could
even quicky determine if the module (or any of its imports have) defined
a selector, and if not, optimize out the module prefix.  Changing a
module's prerequisites, or adding a new method, would require that any
methods sending that message (in the module or its dependents) be
re-compiled (but this is only needed for optimization).

Collecting all symbols defined by a module would only require plucking
them out of the symbol table, and if desired, this too could be
optimized by keeping a local symbol table for each module (and keeping
it in sync with the main symbol table).

- Stephen





More information about the Squeak-dev mailing list