Re: toplevel namespace justification

Ruby
1

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. :wink:

Regards,

Dan

2

On 11/15/05, Berger, Daniel [email protected] wrote:

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

3

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.