# Toplevel namespace justification **URL:** \ **Category:** Ruby\ **Created:** [November 15, 2005, 9:10pm UTC](https://www.ruby-forum.com/t/toplevel-namespace-justification/48001 "2005-11-15T21:10:29Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\ **Post date:** [November 15, 2005, 9:10pm UTC](https://www.ruby-forum.com/t/toplevel-namespace-justification/48001/1 "2005-11-15T21:10:29Z")
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? On the otherhand perhaps it should be FREELY usable and a way should be provided to mitigate if neccessary, for example: module SafePlace import ‘somebodies/toplovel/stuff’ end Or is this approach problematic? I should point out we don’t have a selective #include either, so for example: module MySpace class X ; end class Y ; end end How could one pull X up to toplevel if they wanted w/o bringing Y? Perhaps: X = MySpace::X but there is a caution here b/c poorly written classes would have problems with this. Okay, I’m starting to get off on a tagent, but the original question remains: how should we handle the toplevel space a cooperative community? T. ---
**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\ **Post date:** [November 15, 2005, 10:41pm UTC](https://www.ruby-forum.com/t/toplevel-namespace-justification/48001/2 "2005-11-15T22:41:17Z")
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 H. ---
**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\ **Post date:** [November 15, 2005, 10:59pm UTC](https://www.ruby-forum.com/t/toplevel-namespace-justification/48001/3 "2005-11-15T22:59:20Z")
Some good points. And while I am inclinded to agree Kirk’s comment: ``` "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" ``` raises an interesting conundrum. If I were to address this by splitting out most of the class/modules of Facets into indivdual projects, then many of those very same toplevel namespaces would get used up anyway. B/c of issues like this I get the feeling that there might be a better way than the present convention (which appears to be basically an adaptation from Perl). T. ---
**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\ **Post date:** [November 15, 2005, 11:05pm UTC](https://www.ruby-forum.com/t/toplevel-namespace-justification/48001/4 "2005-11-15T23:05:22Z")
On 11/15/05, Trans [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > When is using the toplevel constant namespace justified? I think the general rule should be as Kirk says, “keep all of your junk inside your own namespace”. > How could one pull X up to toplevel if they wanted w/o bringing Y? > Perhaps: > > X = MySpace::X > > but there is a caution here b/c poorly written classes would have > problems with this. I guess one of the reasons people pollute the toplevel namespace is because they don’t know how to write well-behaved classes that can be pulled up in this manner when required. Perhaps documenting how to do that correctly would be a start. Regards, Sean ---
**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\ **Post date:** [November 15, 2005, 11:17pm UTC](https://www.ruby-forum.com/t/toplevel-namespace-justification/48001/5 "2005-11-15T23:17:25Z")
On Tuesday 15 November 2005 2:57 pm, Trans wrote: > raises an interesting conundrum. If I were to address this by splitting > out most of the class/modules of Facets into indivdual projects, then > many of those very same toplevel namespaces would get used up anyway. > > B/c of issues like this I get the feeling that there might be a better > way than the present convention (which appears to be basically an > adaptation from Perl). Split them up into separate mini projects. Have them all live under Facets:: Then, if you want, provide a simple mechanism to promote them to being accessible from the top level, so that the user can decide whether to use them in the nice, safe Facets namespace, or whether they see enough benefit to having the class at the top level. Might be an interesting discussion to talk about this aspect. For example, let’s say my Webcache were in Facets as Facets::Webcache. If someone wants to use it at the top level, they can do: Webcache = Facets::Webcache Does there need to be anything more sophisticated than that? I haven’t conclusively convinced myself, but right now I am thinking that not doing anything special and thus keeping it transparent and simple. Kirk H. ---
**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\ **Post date:** [November 16, 2005, 2:18am UTC](https://www.ruby-forum.com/t/toplevel-namespace-justification/48001/6 "2005-11-16T02:18:05Z")
Okay, I found this: [RCR 289: Method to import a source file wrapped in a named module](http://www.rcrchive.net/rcr/show/289). I’ve been working on related code so I know how to implement this readily and will do so and make available soon. T. ---
**Author:** ![transfire](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c67d28/32.png) [@transfire](https://www.ruby-forum.com/u/transfire)\ **Post date:** [November 15, 2005, 11:44pm UTC](https://www.ruby-forum.com/t/toplevel-namespace-justification/48001/7 "2005-11-15T23:44:32Z")
> Might be an interesting discussion to talk about this aspect. > For example, let’s say my Webcache were in Facets as > Facets::Webcache. > > If someone wants to use it at the top level, they can do: > > Webcache = Facets::Webcache Sure. But waht if you decided to release Webcache as an independent project…not out of the question, certainly. Then it would end up in the toplevel namespace anyway. Others have done. Instead of participating in a larger collection they’ve just released their single class/module as a project in and of itself. I think we may be dealing with name clash issues b/c we are uneccessarily depending on absolutes defined by other users, and thus outside the realm of our control when putting them to use. Of course some will say it’s too rare to worry about. But as Ruby grows the less that argument holds up --there’s already been some notable occurances. So what about the alternate possibility of “requiring into” an arbitrary namespace? T.