On Nov 30, 2006, at 1:13 AM, Göran Krampe wrote:
Eh, no... But if you look at typical namespace solutions like for example how it works in Java-land - then they suffer from this effect. Everyone happily sits in their own little "pessimistic" sandbox and invents yet another Date, BigNum, Socket or whatever...
There's a difference, I think. Many of those cases I've seen in the world are ones where people consciously chose either a) to replace or extend a system facility with their own special one to meet special needs, or b) most commonly, are simply using the most natural name for a component of their work - which is often the most natural name for someone else's unrelated component of their work.
Neither is one in which there is value in assisting in the merging of these two classes (whatever it would mean to assist that, beyond letting them coexist without any inconvenience, which they generally do.)
One of the nice things about working in a namespaced system is that you can happily choose short, simple names for the innards of your stuff, and not be penalized when other people do the same.
This is one of the "how would it play out" concerns I have about the idea of doing away with explicit disambiguation (by some sort of import mechanism)... in practice, it means all the most likely names I'd like to use for this and that would be the ones most likely to trigger :: display.... good short names for useful internal doobers would be consumed rapidly, and I'd find myself seeing and typing far more '::' than I'd like, or going back to finding globally unique names for all such things.
-b