From: Intransition <transfire@...>
Date: 2009-12-11T12:48:58+09:00
Subject: Re: "private" modules



On Dec 10, 4:01 pm, Matt Bleh <phreakuenc...@gmail.com> wrote:
> Hi,
> I'm writing a ruby library, under a module named "A". Since I provide
> classes which share names with standard ruby classes (like Vector), this
> way I avoid namespace pollution when requiring my library.
> The problem is that I have an inner ("private") module "B", defined
> under "A" where I have a bunch of methods defined that these classes
> will use (I'm using RubyFFI).
>
> But, since (as a user of my library) I would want to "include A" to
> avoid the A:: prefix everywhere, the inner module "B" would be exposed
> to the top-level.
> I don't think it may be really problematic, but I think it may be a
> common issue that others may face.
>
> An example:
>
> module A
>   # I provide a nice Vector implementation, to replace Ruby's
>   class Vector
>     def func
>       # ...
>       B::c_library_func(p)
>       # ...
>     end
>   end
>
>   module B
>     extend FFI::Library
>     attach_function :c_library_func, [ :pointer ], :void
>     # and continues...
>   end
> end
>
> If I do:
> include A
> Now B is visible to the user, and it may end-up clashing with something
> else.
>
> Is there a guideline for these cases?

What is the use case of B? Is it only important to Vector or
subclasses of it, then put it inside Vector.

Otherwise, probably nothing to worry about. You can't clobber a
constant by using include if it already exists.

  >> module A
  >>   module B
  >>     def self.b; "B"; end
  >>     def self.q; "Q"; end
  >>   end
  >> end
  => nil
  >> module B
  >>   def self.b; "B!"; end
  >> end
  => nil
  >> B.b
  => "B!"
  >> include A
  => Object
  >> B.b
  => "B!"
  >> B.q
  NoMethodError: undefined method `q' for B:Module