Recent message threads ("Steps to Modularity - Nested Global Variables" &
"Dot notation and a crazy idea")have discussed various alternative syntax
for disambiguating identifier references in the context of multiple name
spaces. The general assumption in these threads is that some sort of
explicit qualification of identifiers at the point of reference is
necessary. Renaming is an alternative  disambiguation technique that does
not require explicit qualification.

Assume that "Module1" defines an entity (variable) named "Foo" and that
"Module2" defines a different entity also named "Foo". What if code in
"Module3" needs to independently reference the "Foo" named entities from
both "Module1" and "Module2"? There are basically two alternative
approaches that have been applied to this problem in programming languages:
explicit qualification and explicit renaming.

Using explicit qualification, a syntax is provided for qualifying
identifiers with their defining module name at the point of reference.
This is "dot notation":
	Module1.Foo	"refers to Foo as defined in Module1
	Module2.Foo	"refers to Foo as defined in Module2
The qualification of the name must occur at every point within "Module3"
where there is a reference to the ambiguous name "Foo".

Using explicit renaming, a mechanism is provided for explicit assigning new
names (aliases) to identifiers import from alternative modules.  For example:
	Module3 import: #foo from: Module1 as: #Foo1.
	Module3 import: #foo from: Module2 as: #Foo2.
Within Module3 the identifier Foo1 and Foo2 are used to reference the two
entities. The identifier Foo is not used (unless otherwise explicitly
defined by Module3). The import/renaming specification occurs once as part
of the definition of a module or external to the module as part of a module
composition specification. 

There are pros and cons to both techniques and many languages include
support for both.

Some of the advantages of renaming:
	No new expression level syntax required.
	Better abstraction - expressions concern themselves with an entity, not
where it is defined.
	Maluability - only a single place needs to be changed if modules are
refactored.
	Late binding - The source of an entity can be defined after referencing
code is written.
	Selector name spaces - can be applied to message selectors as well as to
"variables".

At the OOPSLA'96 Workshop on Extending Smalltalk I presented a proposal for
Smalltalk name spaces that used explicit renaming instead of qualification
and that provided for selector name spaces. This proposal can be found at
http://www.smalltalksystems.com/publications/subsys.pdf
Note that while the proposal is written from an ANSI Smalltalk
"declarative" perspective the basic concepts are equally applicable to a
dynamic reflective environment such as Squeak.

Allen_Wirfs-Brock at Instantiations.com