From: E S <eero.saynatkari@...>
Date: 2004-12-31T03:32:48+09:00
Subject: Re: Namespaces, inverted


> L�hett�j�: E S <eero.saynatkari@kolumbus.fi>
> > L�hett�j�: Joel VanderWerf <vjoel@PATH.Berkeley.EDU>
> > 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? 

Alternatively, of course, the parser could look for
module/class declarations that are *not* standard
(e.g. 'module MyMod').

This, as the above example, still leaves the problem
of nested classes/modules, which would have to be
parsed for with some sort of a state machine. But
it really is too complex to implement in anything
but low-level C internally, where some shortcuts can
be taken.

E