Hi,

Goran, I like most of what you proposed.
After reading Andreas answer, I started thinking about imports.
I belive that to increase reuse opportunities imports should not be 
bound inside namespaces.
Instead, when loading a namespace into an image, one should be asked to 
link names
that are not resolved inside the loaded namespace with objects available 
in other namespaces
already in the image.

Example
Suppose I have namespace A providingclasses L and M.
Then I load/create namespace B where X and Y are not bound.
System should ask me wich classes to use for X and Y. I can choose
to L and M. Then X and Y in namespace B are just aliases to L and M.

Now, I "fileout" my namespace B so it can be used in another image 
(Andreas, should I talk about
another "context"?) with two namespaces C and D. Suppose that C holds a 
class Z and D holds
a class W. Here, I can bound X and Y of namespace B to Z and W (that are 
in two different
namespaces).

To sum up, what I suggest is:
-a namespace should state what it needs, but not from where to get it 
(no hardwired import). The location (namespace) of imported classes 
should not be visible in the code inside namespaces (so no need of extra 
syntax stuff and source code never change). But, one should be able to 
findout connections between namespaces.

-allow refering to classes with different names (aliasing). This means 
not rely on names for retreiving classes required by some namespace. In 
order to keep the "optimistic" approach of Goran, this should be viewed 
as an extra possibility. When loading a new namespace, the system can 
try to fulfill requirements based on class names, but one should be able 
to refer to classes with different names.

Noury

-- 
------------------------------------------
Dr. Noury Bouraqadi - Enseignant/Chercheur
Ecole des Mines de Douai - Dept. G.I.P
http://csl.ensm-douai.fr/noury

European Smalltalk Users Group
http://www.esug.org 

Squeak: an Open Source Smalltalk
http://www.squeak.org 
------------------------------------------