goran.krampe at bluefish.se wrote:
> So there is no "escaping" going on here. In my code I would write
> Network::Socket in my code and that would be it. Plain to see. No
> problem. And if you want to see what namespaces a certain class or
> namespace uses? Easy - just collect all those references! And if you
> want to fileout a class and into another system? Easy again, works just
> fine because the references are *right there*.

If I am following the discussion correctly, Stephane's argument -- which
I have a lot of sympathy for -- is that you should never write
Network::Socket in your code.  You should import "Socket" at a larger
scope.

What do you think?  Why is it okay to have all these explicit namespace
dereferences scattered through your code?


> Having "imports" on the namespace level IMHO creates more headaches than
> it solves. For example - if I move a class to another namespace (using
> my namespace model) - no problem, it just works.

Whoa, you don't want to have them at all?  That is extreme and (to my
knowledge) novel.  At the very least, won't this be annoying in a
thoroughly namespaced world?  Do we have to type Collections::Array to
get an array?  Morphic::RectangleMorph?


Imports seem important, and it is worth thinking about how they will
work.  It is fine to say that you don't answer the imports question, but
it is a question that needs to be answered eventually as far as I can
see  (what alternative is there?).  Ideally, the model of namespaces
themselves should at least *support* a good imports mechanism.
	

-Lex