> You get very similar advantages when you consider all references to  
> "outside" globals be really definitions inside the module's  
> namespace itself. In other words, if module Foo would use "Array  
> new" it would really mean "Foo::Array" (e.g., the value of #Array  
> inside the module Foo) and you could populate (parametrize) that  
> via, say "Foo::Array := Collections::Array" etc. This has the added  
> advantage that there is no true "global" access to anything (e.g.,  
> no ambient authority beyound what was explicitly given to the  
> module) and that multiple modules can co-exist with different  
> parametrizations.


Hi andreas

in fact I like the idea that a module only refer to its own names and  
that these names can point to other names by contrast with an  
approach where all code of the modules can refer to foreign names.

This is what we tried to have in classboxes with import statement.  
After the notion of parametrization
is based on where the import is specified. If this is outside a  
module and you can "duplicate code" then you get effective  
parametrization. Else you get modules that you can parametrized but  
you cannot get two at the same
time in memory

I once asked Dan if having import statement at the modules boundaries  
would help the image-segment
analysis (since you would not have to go through all the code) just  
the local name base of the module you want to save. But dan never  
replied :)


Stef