Modules
Colin Putney
cputney at wiresong.ca
Sat Feb 26 04:07:37 UTC 2005
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
More information about the Squeak-dev
mailing list
|