# Re: toplevel namespace justification

**URL:** <https://www.ruby-forum.com/t/re-toplevel-namespace-justification/102485>\
**Category:** Ruby\
**Created:** [November 15, 2005, 11:14pm UTC](https://www.ruby-forum.com/t/re-toplevel-namespace-justification/102485 "2005-11-15T23:14:25Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Daniel.Berger](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ac8455/32.png) [@Daniel.Berger](https://www.ruby-forum.com/u/Daniel.Berger)\
**Post date:** [November 15, 2005, 11:14pm UTC](https://www.ruby-forum.com/t/re-toplevel-namespace-justification/102485/1 "2005-11-15T23:14:25Z")

</div>

> I think the general rule should be as Kirk says, "keep all of  
> 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

Blech.

If I want to bring X up to the toplevel, I simply do “include MySpace”  
at the top of my code, where I assume “MySpace” is a module. I realize  
this convention could be abused, i.e. someone could stick instance  
methods inside “Net” for example, but so far (years now) it just hasn’t  
been an issue. Community policing and general common sense work well  
enough.

If we _really_ felt the need for a namespace, we would have to add a  
“namespace” method/keyword/whatever to Ruby, which would (I imagine)  
simply be a special form of module. Just rip out all the methods and  
disallow defining new methods. Not all that useful or needed, though,  
imho.

I now await the implementation of “namespace” Florian G. has laying  
around on his hard drive. 😉

Regards,

Dan

---

<div class="post-metadata">

**Author:** ![Daniel.Berger](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ac8455/32.png) [@Daniel.Berger](https://www.ruby-forum.com/u/Daniel.Berger)\
**Post date:** [November 16, 2005, 2:18am UTC](https://www.ruby-forum.com/t/re-toplevel-namespace-justification/102485/2 "2005-11-16T02:18:05Z")

</div>

On 11/15/05, Berger, Daniel [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Blech.

Lol! What did I say that made you blech? 🙂

> If I want to bring X up to the toplevel, I simply do “include MySpace”  
> at the top of my code, where I assume “MySpace” is a module.

Yeah, but when you have something like this (imagining FooObject and  
ModFoo::FooObject defined in separate files required by different  
libs):

class FooObject  
def self.show  
puts “toplevel #{self}”  
end  
end

module ModFoo  
class FooObject  
def self.show  
puts “ModFoo #{self}”  
end  
end  
end

include ModFoo  
class Bar \< FooObject  
end  
Bar.show  
#=\> expecting “ModFoo B.” but get “toplevel Bar”

The other method:

FooObject = ModFoo::FooObject

class Baz \< FooObject  
end  
Baz.show  
#=\> ModFoo Baz

works but provokes:

#=\> test-top-level.rb:20: warning: already initialized constant  
FooObject

and AFAIR, constants are going to be harder to redefine in future.

I agree that mostly this all works out OK but when it doesn’t it can  
lead  
to unexpected behaviour the cause of which is hard to track down.

A real-life example of this came up recently with the Qt lib (Qt::File  
occluding File) - see ruby-talk/161157.

I can see this kind of thing happening more often now the Ruby  
community has started to grow by leaps and bounds unless there is  
general agreement  
on the ground rules.

I understood that Trans was canvassing opinion for a consensus on what  
everyone thought was best practice to avoid such clashes. IMHO,  
avoiding the toplevel namespace is best practice.

Regards,

Sean

---

<div class="post-metadata">

**Author:** ![Daniel.Berger](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ac8455/32.png) [@Daniel.Berger](https://www.ruby-forum.com/u/Daniel.Berger)\
**Post date:** [November 16, 2005, 3:29pm UTC](https://www.ruby-forum.com/t/re-toplevel-namespace-justification/102485/3 "2005-11-16T15:29:14Z")

</div>

Sean O’Halpin wrote:

> module ModFoo  
> class FooObject  
> def self.show  
> puts “ModFoo #{self}”  
> end  
> end  
> end
> 
> include ModFoo

Shouldn’t Ruby raise an error right here? I mean wouldn’t that make the  
most sense? Othere than that might we not expect the included class it  
to override the original?

> end  
> Baz.show  
> #=\> ModFoo Baz
> 
> works but provokes:
> 
> #=\> test-top-level.rb:20: warning: already initialized constant FooObject
> 
> and AFAIR, constants are going to be harder to redefine in future.

Oh dear. Could you eleborate on this? What will change? If constants  
are going to cause even worse problems of this nature in the furture I  
just as soon see them tossed altogether. Ruby’s a dynamic lanaguge.  
Constants are good for DRY, but enforced staticness is not a plus for  
Ruby, IMHO.

> I agree that mostly this all works out OK but when it doesn’t it can lead  
> to unexpected behaviour the cause of which is hard to track down.
> 
> A real-life example of this came up recently with the Qt lib (Qt::File  
> occluding File) - see ruby-talk/161157.

Another example very recently was Glue lib on TextDrive machines.

> I can see this kind of thing happening more often now the Ruby  
> community has started to grow by leaps and bounds unless there is  
> general agreement on the ground rules.
> 
> I understood that Trans was canvassing opinion for a consensus on what  
> everyone thought was best practice to avoid such clashes. IMHO,  
> avoiding the toplevel namespace is best practice.

True. And while I agree with you finaly assesment, when it comes to a  
general pupose library like Facets I’m not so sure for the reasons I  
stated earlier. So now I feel a kind of stuck between two realms. I  
think that the “right way” _probably_ is per RCR 289, but that has no  
support via core Ruby. Yet, I have written the support myself in pure  
Ruby which works well enough. So which route do I choose?

T.