Namespaces (was: Re: [ANN]A plan for 3.8/4.0... (insertdrumrollhere))

stéphane ducasse ducasse at iam.unibe.ch
Sat Apr 3 09:28:50 UTC 2004


> As Andreas points out, the tough part about implementing namespaces 
> (and Traits
> and Classboxes and Packages and every other experiment at the 
> meta-level) is
> making the tools support it smoothly. Insert my shameless plug for 
> OmniBrowser
> here. Making this sort of thing easier it what it's for.
>
> Also, I think Goran's point is well taken, and it suggests a deeper 
> issue. I
> think we'd all agree that some way of handing naming conflicts will be
> necessary as we move more and more towards images built by loading
> independently maintained packages. However, if we want Squeak 
> namespaces to be
> more than a checklist feature, we need to decide what their purpose 
> is. The
> complexity they add to the system had better solve a real problem, and 
> if we
> can identify the problem clearly, I think the desired semantics will 
> be pretty
> clear as well.
>
> This sounds obvious, I know, but I'm not clear on the whys behind the
> implementations proposed so far. Stephane, you mentioned that 
> Classboxes are
> meant to protect the system from broken packages. Is there more to 
> that?
> Andreas, why did you add namespaces to Tweak? Avi, what do you want to
> accomplish with your proposal?

I think that you are asking the right questions:
	- goal
	- impact on the environment

The choice of andreas was how to support namespaces without impacting 
the scope of the
user with unnecessary symbols and preserving as much as possible as the 
current environment.
(I was driving late yesterday and I tried to understand what I wanted 
to say in my idiot post). But the
price is that you have somehowe explicit namespace or scope access. So 
as a user I may see that there are namespace and refer to symbol 
outside the world. (for me doing that what was I called programmer 
audience vs a scripter would not have to worry or have the possibility 
to use the :: operator).

Our goal was not conflict resolution such as prefix, but how can we 
control the scope of changes.
How a class extension can be controlled (a bit in similar way that 
selector namespaces)? So a namespace is implied in classboxes but this 
is not the main point. This is an implementation consequence. Our 
idea/question is: what is the smallest mechanism that lets me believe 
that the world is the one I see from my perspective (without explicit 
context operator like in Us) and without explicit namespace references. 
How can I make sure  that if I change a method in another classbox this 
modification will be only seen by me (note that this changes should be 
seen
if I call another method that calls the modified methods, we called 
that local rebinding).
The idea is that I can load code in a classbox and if the code redefine 
OrderedCollection do:
the other classbox and the system should not break apart. It will when 
I execute an expression in the classbox breaking the system.
Now this has some costs:
	- we need another environment that is class box aware (what andreas 
solution avoid
	- we need another lookup (for local rebinding) but local rebinding is 
not intrinsically
	linked with classbox this was more a research experience to see how 
far we can go
	Alex modified the VM but now as a solution that does not require it. 
He will provide
	a version that does not have local rebinding so that people can play 
with classboxes.
	

Our goal is not to have namespace in Squeak or even classboxes. We will 
experiment with our
own languages and people can use it or not.








More information about the Squeak-dev mailing list