Quoting Andreas Raab <andreas.raab at gmx.de>:

> Yet, at some point you *do* have to use these guys or else
> you can't compile anything. You have two choices:
> a) "Import" all of them, e.g., make these guys globally accessible,
> spoil the end-user namespace by exposing it directly.
> b) Explicitly qualify the name, e.g., make it "deliberately obscure in
> the end-user space" to keep it out of the user-visible set of names.
> I vastly prefer the latter.

I've been thinking about namespaces too, although in the context of loading
packages in Monticello. My idea for "really simple namespaces" amounts to a
refactoring of Compiler, and goes like this:

Instead of compiling in the context of a class, the compiler would instead by
passed a Namespace, which would implement #bindingOf: and maybe a few other
methods. A Namespace would be a list of Scopes - dictionaries basically - which
would be searched in order whenever the compiler requests a binding for a given
symbol.

By default, namespaces would be constructed analogously to the current
inheritance-based lookup process. That is, classes would respond to #namespace
and #scope; #scope would answer a flat mapping of symbols to objects and
#namespace would answer a Namespace built by sending #scope to all the classes
in the inheritance chain.

For special situations, it would be possible to build custom namespaces. For
example, web applications or scripting systems could build "safe" namespaces
for evalutating code entered by the user. Or Monticello could build a package
in a sandbox before installing it.

Two other thoughts:

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?

Cheers,

Colin