Forum: Ruby Re: toplevel namespace justification

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F3b7b8756d0c7f71cc7460cc33aefaee?d=identicon&s=25 Daniel.Berger (Guest)
on 2005-11-15 23:14
(Received via mailing list)
> 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 Gross has laying
around on his hard drive. ;)

Regards,

Dan
E1d641bfe4071a5413bac781f06d3fd1?d=identicon&s=25 Sean O'halpin (sean)
on 2005-11-16 02:18
(Received via mailing list)
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
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-11-16 15:29
(Received via mailing list)
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.
This topic is locked and can not be replied to.