From: Robert Klemme <shortcutter@...>
Date: 2009-12-11T07:15:52+09:00
Subject: Re: "private" modules

On 12/10/2009 10:01 PM, Matt Bleh 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?
> 
> Thank you

You might be able to pull this off with instance or local variables:

module A
   @b = Module.new # or b = ...
     extend FFI::Library
     ...
   end

   Vector.send :include, @b
end

# untested

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/