>> 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.
>
> That's good advice. Let me point out what the most important thing 
> about
> "namespace semantics" for me is: Give it as little semantics as 
> possible!
> Don't mangle it up with packages, don't mix it with trying to do
> encapsulation! The (failed) modules approach in 3.3 mixed these issues 
> up
> and ClassBoxes look dangerously similar in this respect. However, I 
> would
> opt for a namespace implementation that leaves *any* of these aspects
> completely out. It could then be *used* by ClassBoxes, it could be 
> *used* by
> packages but mixing up the name scope with any other kind of semantics 
> is a
> recipe for desaster since it makes it impossible to associate any 
> other kind
> of semantics with them and will therefore lead to lots of ugly 
> conflicts.

I agree....:)
I got a lot of meta-thoughs about mixing packages and scope. And I'm 
not really satisfied.
Joseph always told me namespace is for scope, module/package for 
deployement

We tried to separate the two but the results was really complex. So I'm 
not claiming that
we have the solution and that people should use it. We have one 
solution and we will
experiment with it and may be kill it or improve it.

>> 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?
>
> For Tweak, the answer is simple: The first goal is that I want to be 
> able
> that users can use names like "Button", "ScrollBar", "Window" without 
> having
> to remember ugly prefixes or confusing them with any of the MVC or 
> Morphic
> variants. Since there is ZERO overlap between Morphic/MVC and Tweak it 
> is a
> way of defining the "universe" you live in. Secondly, I want to be 
> able to
> "hide" precisely these names which would be conflicting and confusing 
> from
> the first-order user name space. Thirdly, I wanted to be able to build 
> a
> fence before you are able to use some names - say ClassBuilder not 
> appearing
> in the first-order set of names but rather being put a little 
> side-ways out
> of "immediate reach" for the user.
>
> As you can see, all of these goals are about "names" and not about
> semantics. And that's what a namespace should provide - access to 
> names and
> nothing more.
>
Yes.