Toplevel namespace justification

ruby-talk
1

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 Gross has laying
around on his hard drive. :wink:

Regards,

Dan

···

-----Original Message-----
From: Sean O'Halpin [mailto:sean.ohalpin@gmail.com]
Sent: Tuesday, November 15, 2005 3:04 PM
To: ruby-talk ML
Subject: Re: toplevel namespace justification

On 11/15/05, Trans <transfire@gmail.com> 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

2

Blech.

Lol! What did I say that made you blech? :slight_smile:

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 Bar" 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

···

On 11/15/05, Berger, Daniel <Daniel.Berger@qwest.com> wrote:

3

Sean O'Halpin wrote:

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

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?

class Bar < FooObject
end
Bar.show
#=> expecting "ModFoo Bar" 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.

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.