On 11/15/05, Berger, Daniel <Daniel.Berger / qwest.com> 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 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