Hi Colin,

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

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

Cheers,
  - Andreas