From: Kirk Haines <khaines@...>
Date: 2005-11-16T06:38:44+09:00
Subject: Re: toplevel namespace justification

On Tuesday 15 November 2005 1:07 pm, Trans wrote:
> When is using the toplevel constant namespace justified? (Other then
> for creating your own namespace obviously) Should it essentially NEVER
> be used? Or is there some cases where it is reasonable? For instance
> some classes seem so basic they feel like they belong there, like a
> Tuple class. But perhaps the space should be reserved for Ruby built-in
> stuff only, PERIOD?

It is good practice to keep all of your junk inside your own namespace, 
especially if you are making anything for others to use.  Otherwise, no 
matter how lucky you think you are, eventually there is going to be a 
namespace collision with someone else's code.

The only times that I can see an exception is when one is working within the 
context of a core class, or when one is writing something that is not 
intended for public consumption.

It a problem that I have wrestld with in my head, as I have a few classes 
internal to IOWA that could be general purpose libs.  I don't want to offer 
them for inclusion in Facets because *I* don't want to have to have a 
dependency on such a large collection when I'm only using a few bits of it, 
but that's another subject....  Anyway, what I have decided on is modifying 
the classes so that they, by default, stay in the the Iowa namespace when 
required, but so that one can tell the class to pollute the toplevel 
namespace and make itself available through there, too, if desired.

So, people who want to use Iowa::Webcache, but don't want the Iowa:: part 
hanging out there can have it as just Webcache, even though that is much more 
likely to collide with someone else.

So yeah, in general, keep the toplevel as unencumbered as possible.


Kirk Haines