> > 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.
>
> It depends what is your audience. I prefer a model that does not lie in
> my back.

It's not a "lie" to keep the user visible namespace clean and
understandable. It's not a lie to have fences. Would you call it a lie that
ClassBuilder handles AttemptToWriteReadOnlyGlobal so it does things that
you, the user/programmer can't easily do? Would you call it a lie that the
VM uses pointers where you, the user/programmer can't use them?

It's in particular not a lie because it doesn't remove any power from the
system. It simply says that if you want to use it, you have to be a bit more
explicit. It simply says, you are allowed to do some things (which may be
considered stupid) and the system won't break on you.

> But I can understand that if you are building an environment for
> scripters or novices you do not want to pollute them with unnecessary
> symbols. In Classbox we took the decision to have transparency
> but for a full programmer audience.

Stef, that's ridiculous - it has absolutely nothing to do with a "full
programmer audience". The key point about namespaces is that it keeps the
names that you use concise and easily understandable. Do you think even
programmers like the idea that instead of just remembering "I want to use a
Button" they have to guess about "oh, is it called ButtonMorph?
MorphicButton? SimpleButtonMorph?"

Cheers,
  - Andreas