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.