> this is very true ! personal testimony: in my development I wrote 
> hundreds of classes, and I'm worried every time a simple obvious name 
> comes to mind. so I end up prefixing everything with an ugly and 
> meaningless SPFA (my initials), or taking the risk to name a class 
> Silence (I'm into music composition)

It's not meaningless because the name conveys that its your style, your
implementation, your solution to music-composition in a world where there can
and should be hundreds of music-composition programs, even with lots of
overlapping functionality.

When I see "MC" it tells me a ton about what to expect from that software. 
Where else could you get so much utility out of two letters?

For software to have a "personality" is a good thing, IMO.  "Reinventing the
wheel" is not always a bad thing because it's actually building a better
mousetrap.  "Better" meaning, "more-suitable" for MY needs.

Also, it's really not much different than prefixes using ::, except they're
always "fully-qualified", and you probably get more meaning from them because
they're not "unified" names.

> I guess a lot of persons have brilliant ideas about what 
> String>>#format: should do... so the need for some kind of namespace is 
> obvious to me.

Actually, I think this reinforces Martin's point.  Namespaces allow, sometimes
even encourage, meaningless, non-descriptive names like this to perpetuate.

As I move away from large, monolithic, everything-and-the-kitchen-sink images
to smaller, network-connected images that each serve more-specific purpose the
image-as-a-namespace becomes more relevant.  Multiple namespaces in a single
image become less important, so let's not allow the solution to create issues,
please.

So far, I think I like Göran's proposal.

 - Chris