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