On Feb 25, 2005, at 4:03 AM, stéphane ducasse wrote:

>> Agreed. I've already mentioned that I'd like to see a decoupling 
>> between the structure of the program elements in the image and the 
>> compiler's binding of names to objects. The Forth strategy sounds 
>> right to me.
>
> I'm not that sure in fact.
> If you look in VW the worse to me is class level namespace import.

I agree that class-level namespace import is a pain. But I think to 
focus on that is to miss the forest for the trees. The problem is not 
that the imports are on classes rather than modules, but that they are 
properties of the code rather than its environment. (And I don't mean 
the environments we have in Squeak already, I mean the context in which 
the code finds its self when it is loaded into an image.) Let me put it 
another way: An import is fundamentally a relationship between the 
module and something outside its self. If you define that relationship 
within the module, be it per-module, per-class, or per-method (eg. with 
fully-qualified names), you're hardcoding within the module the 
structure that its environment must have when it is loaded.

I'd like to see a system where the relationship a module has to its 
environment is defined when it's loaded into that environment, by 
whomever is doing the loading - ultimately, the user. When loading a 
module, we'd provide the loader with a context, which would supply a 
way of resolving names (#bindingOf:, basically), and a way to bind new 
objects into the namespace being constructed (#at:put:). The Compiler 
and ClassBuilder would use the context to link up the new module with 
it's environment.

Now, that loading context could encapsulate whatever kind of policy you 
want. We could have an EnvironmentContext that provides exactly the 
same behaviour we have in Squeak today. You could have another context 
that held a Forth-style (I guess) list of namespaces with a search 
order. You could have a SandboxContext that made it impossible to 
reference dangerous code, or an Atomic context that used a sandbox 
temporarily, and then linked the new module into the image atomically. 
You could even have a ClasspathContext if you were into that sort of 
thing.

> Finally what I like with classbox namespace part (not the fact that 
> class extension are scoped (which I like but is another point), is 
> that for a developer when I'm coding my method I do not think that 
> there are namespaces around. When a name is not found, the borwser pop 
> up and asks me, I found two Array classes in the system, then I pick 
> one and there is an import statement added in the namespace and this 
> is it. After I can see array as normal. The first paper on classbox is 
> http://www.iam.unibe.ch/~scg/Archive/Papers/Berg03aClassboxes.pdf But 
> again I'm not sure that we need them.

Yup, I like that experience too. I let's do that.

Colin