>>
>> Actually, I don't like this, too. My continuing reacquaintance with 
>> the
>> Smalltalk way of object-orientedness is creating a growing suspicion 
>> that the
>> information hiding concept embodied in the form of the class is too 
>> low-level
>> to be of practical use for structuring complex systems with a 
>> multitude of
>> classes. As it stands currently, I can use any class anywhere in my 
>> code and
>> thus make everything dependent on everything, at least in principle, 
>> which is
>> for me an analogue to spaghetti code.
>
> IMHO dependencies can be bad and good. A good dependency is *meant* to
> be there. For example, my HttpView web framework builds on top of
> KomHttpServer. That dependency is meant to be there so my classes refer
> to classes in KomHttpServer. Of course, minimizing dependencies is
> always nice - but to say that classes in namespace Foo can *never* 
> refer
> to classes in namespace ZZ is really weird to me.

But you can refer to these class but not explicitly.
If your world (in your namespace you can only see your Symbols and the 
one you imported
then you can refer to other classes but conceptually they are not in 
another
namespace. They are in your namespace since you added them to the list 
of symbols
your namespace has.