Thank you Martin!  I agree with you on this and even would like to take it one
step further.

If I'm using a Plot package written by Diego in my program and that's the only
one I like and use, then great.  BUT, if another Plot package becomes available
(with names that conflict with Diego's) that supports 3D-plots and I want to
use it also, then I want a way to *dynamically* "make room" in the namespace
for both to exist.  So "Plot" becomes "DiegoPlot" or something of my choosing
so that "Plot" from the 3D package can be defined.

In a world where there should not be just one operating system, just one
office-suite, or just one plot package, "DiegoPlot" makes perfect sense. 
Irregardless if you think its "ugly", in the real world, "modular" names (e.g.,
DiegoPlot) are useful, "unified" names are confusing (Plot).

But that's not all.  Folks, unless we adopt a prefixing convention similar to
Java, handling *dynamic renames* is NOT OPTIONAL, period!  Otherwise, we are
still in danger of name collisions, and right back where we are today;
scratching our heads on how to get two things to co-exist.

So if the proposed solution only reduces, not eliminates name collisions, I
suggest we consider doing the simplest thing that can possibly work.  NOTHING! 
Er, well, almost nothing.

Consider that we *have* namespaces already.  Every Squeak image is a separate
namespace.  If we embrace Martins point that descriptive names are good anyway,
and agree that we need dynamic renames, namespaces within the image become
unnecessary.

Finding a way for dynamic renames to work reliably, given that classes are
referenced in different ways could be a challenge, but perhaps an appropriate
focus of energy if you all agree.

Thoughts?


==============
Martin Wirblat wrote:

>This will also encourage us to to still have globally unique names in
>our packages which is a GOOD thing because no matter how cool 
>namespaces we have - it all ends up in our heads - and our heads is 
>just one big namespace. If many namespaces have "Delay" entries, it 
>will still mess with our heads.

and referring to SqueakMap::Delay
 
>	2. Rename it to MapUpdateDelay and be fine, that might very well be a
>more precise name.

I think this is a very important point. SqueakMap::Delay tells us 
NOTHING about the nature of the delay, but MapUpdateDelay does. To 
understand a program ( while reading or writing it ), we don't want to 
have the information where something comes from, we want to know what 
it does. 

If we offer to create unique names by "prefixing" with a namespace, we 
may put the fences at the wrong places. People will often choose to 
take the easy road not willing to think about a really describing name 
which would help programming and understanding programs as much as 
possible. 

If you often have to qualify the name fully ( depending on the 
implementation ) the barrier to create a really describing name will 
be raised further. ( SqueakMap::MapUpdateDelay ;-) 

Namespaces may lower the signal to noise ratio of our source code.

Given how fast people here are starting to talk about nested 
namespaces or "partitioning" the whole image into many namespaces, I 
guess implementing namespaces will not automagically "clean up" names 
in the future, it will probably do the opposite. 

Regards
Martin