From: E S <eero.saynatkari@...>
Date: 2004-12-29T05:33:34+09:00
Subject: Re: Namespaces, inverted

> L�hett�j�: Joel VanderWerf <vjoel@PATH.Berkeley.EDU>
> P�iv�ys: 2004/12/27 ma PM 05:50:04 GMT+02:00
> Vastaanottaja: ruby-talk@ruby-lang.org (ruby-talk ML)
> Aihe: Re: Namespaces, inverted
> 
> eero.saynatkari@kolumbus.fi wrote:
>> [Snip]
 
> I like the idea very much, but there are some difficulties...
> 
> def import file
>   file[:module].module_eval(IO.readlines(file[:name]).join)
> end
> 
> class String
>   def as mod
>    {:name => self, :module => mod}
>   end
> end
> 
> module Extern; end
> # It's a little awkward, but you gotta do this first, if
> # you want to refer to the module as below.

I see you caught my use of 'module' there. 
This is the easier problem to solve:

def import file
  # Top-level
  module_eval "module #{file[:module]}; end"
  file[:module].module_eval(IO.readlines(file[:name]).join)
end
  
> libfile = "/usr/local/lib/ruby/1.8/complex.rb"
> # One problem is the cumbersome path name to the library file.

Could set it to look up simple filenames through
the standard ruby paths. Ideally, of course, one
wouldn't be importing the core libraries anyway,
since they're assumed to be habiting the global
namespace.

> import libfile.as(Extern)
> # This fails because the library complex.rb tries to open an existing
> # class, Numeric, and modify its contents. But instead it opens a new
> # module, also called Numeric, that lives inside the wrapper. You can
> # fix this in complex.rb (assuming you want to touch 3rd party code)
> # by referring to the module as ::Numeric when you define it. But
> # there's still a problem...

Here I am modifying String and I didn't think of anyone 
doing the same :)

A solution would be to modify the loaded file String
before eval()ing it: do a 

... =~ /(?:module|class\s(\w+?)/ 
if $ALL_STANDARD_MODULE_AND_CLASS_NAMES.has_key? $1
   # Escape the module name with ::
end

This (obviously) only works for standard modules and
classes and it doesn't take into account top-level
functions... (have to do def Kernel.foo explicitly if 
necessary -any use of that function inside the imported
module would be sort of 'global' since it's in the same
scope anyway) but I'm not sure if it'd be necessary to
take precautions against anything else? 

E