From: Robert Klemme <bob.news@...>
Date: 2004-12-31T04:31:43+09:00
Subject: Re: Namespaces, inverted


"Joel VanderWerf" <vjoel@PATH.Berkeley.EDU> schrieb im Newsbeitrag 
news:41D1D875.8020501@path.berkeley.edu...
> Robert Klemme wrote:
> ..
>> We have Kernel#load [1] with a similar functionality already.  Currently 
>> it accepts an additional parameter to enforce wrapping of the file in an 
>> anonymous module.  That could be extended to accept a module as well; 
>> that then would be the module used.  Then we can do
>>
>> load "foo.rb" # not wrapped
>> load "foo.rb" # wrapped in an anonymous module
>> load "foo.rb", MyExternal # wrapped in MyExternal
>
> Wrapping is a nice idea (see raa:script for one approach), but the wrapped 
> lib will break if it depends on modifying classes or modules in the global 
> scope or defining global methods (the Complex example in my previous 
> email).
>
> There is the idea the OP mentioned of parsing input files and rewriting 
> them to be explicit about the scope of definitions, automating the kludgy 
> hack I proposed for complex.rb. But that will break if the lib uses 
> dynamic code generation.
>
> Maybe library writers should follow a standard of making their code 
> explicit about namespaces:
>
> 1. If you open and existing class, give an absolute path to it:
>
>   class ::Integer
>
> rather than
>
>   class Integer

Totally agree.  I guess this is seldom used these days.

> 2. Global methods defs should be wrapped like this:
>
>   class ::Object
>     def global_meth ... end
>   end

That's really the same as case 1, isn't it?

> 3. References to constants (not just classes and modules) defined in the 
> lib should be relative:
>
>   class Foo
>   end
>
>   f = Foo.new
>
> and not absolute:
>
>   f = ::Foo.new
>
> (although I can't imagine that many libs have this problem).

I think so, too.

> 4. Anything else to protect the lib from breakage when wrapping?

We would have to think about what happens if a wrapped module requires 
another module.  If that other module is a standard module you'll certainly 
do not want it to be included in the wrapping namespace.  If it belongs to 
the same lib, then of course you want it wrapped.  So the crucial question 
is: how are these require's distinguished?  I'm not 100% sure but I think a 
simple 'require "foo"' will look relative as well as in global directories - 
that might be a chance to distinguish...

As much as I like the original idea of wrapping classes in namespaces (much 
the way that can be done with C++ because of #include) I believe this needs 
more thought.

Kind regards

    robert