Re: Matz says namespaces are too hard to implement - why?

Trans wrote:
> Doesn't _why have an interesting approach of this problem? I forget
> what it is called. I think he basically "objectified" the whole of
> Ruby so it was reusable.

Yes, sandbox. There's also discussions starting now about multi-VM 
support in a future Ruby 1.9/2.0 version. Both allow you to isolate a 
"sub-ruby" from changing things in the "super-ruby" but they're far more 
isolated than a selector namespace would be. Basically, in sandbox (and 
in the JRuby equivalents) you have to marshal data between the two 
"rubies" as though they were separate processes. Hardly a seamless 
integration for namespacing, but useful for other domains (_why 
demonstrated multiple Rails apps in the same process, for example).

> Also, I recently posted this to core (doubt it would ease the
> implementation issues however):
> 
> Would it be possible to do selector namespaces on a file basis? That
> is to say, load a library such that it would only apply to the
> immediate file and no other? For example lets say I have:

I'd say yes...but with a caveat: the namespace would only apply to 
invocations within that file. I think in general it's expected that a 
selector namespace would affect called code as well in the same thread. 
But perhaps that wasn't intended by Matz's initial proposals of selector 
namespace behavior?

Maybe we need to get our heads around what selector namespaces should 
actually *be* first...

>   # round.rb
>   class Float
>     def round
>       0
>     end
>   end
> 
>   # foo.rb
>   n = 1.23
>   puts n.round
> 
>   #boo.rb
>   selector_require "round"   # hypothetical
>   require "foo"
>   n = 1.234
>   puts n.to_f
> 
> running boo.rb, we'd get:
> 
>   1
>   0
> 
> The 1 comes from foo.rb, but the 0 from boo.rb because we "selectively
> loaded" round.rb.

This is an example of something I'd expect to *not* work, because 
"round" is not called after the namespace is installed. Did you mean to 
call n.round at the bottom? That I would expect to work...but no calls 
to round outside this file would see the namespace.

This version would also suffer from constantly checking if a namespace 
has been installed, since the calls after are independent and 
selector_require would presumably be just another method call. However a 
  file pragma that says "this file operates under a given selector" 
would probably work well...since all calls in that file could be 
decorated with namespace checks during parse.

> I've never been satisfied with block-oriented approaches often cited.
> Is this perhaps a more useful approach?  Or does this have problems of
> it own?

Blocks at least allow the interpreter to say "within this context, use 
this namespace" and provide an "off" point where the namespace goes 
away. I'm not sure either approach is better than the other, but the 
pragma is probably the least impact to performance (and maybe the least 
useful).

In the end the biggest problem that namespaces introduce is that dynamic 
invocation becomes...even more dynamic, since every call can suddenly 
take a path completely unrelated to the object being invoked if the 
namespace decides it should do so. This is the crux of the issue in 
Groovy, and until there's a way to make namespaces have zero perf impact 
on non-namespaced code I'd vote to keep them out.

But I still think it's worth discussing exactly what they should do and 
how they should work.

- Charlie