On 26 févr. 05, at 5:07, Colin Putney wrote:

>
> 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.

I understand and this is not incompatible with import and the fact that 
as a programmer we do not have to deal
with multiple namespaces awareness inside the method body.

> 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
>
>