Squeak and Namespaces

brad fowlow fowlow at pacbell.net
Thu Nov 30 09:35:22 UTC 2006


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061130/5615e029/attachment.htm


More information about the Squeak-dev mailing list