Charles Oliver Nutter wrote:
>> Is there a good example of where and why per-thread namespaces would 
>> make it that much more useful you imply, so I can follow your argument 
>> of thread unaware namespaces being worthless?
> 
> They wouldn't "have to be" but that would probably be the most useful.
> If I have a namespace that changes String#to_s and I call a library that
> calls String#to_s, don't I want that library to see my change?

Hm, my knowledge about AOP is very limited, but this sounds more like 
AOP to me than namespacing.
I'd expect (and want) a namespace only to be effective for libs that 
know about the changes and request them (by importing the namespace 
where the change is made e.g.)

> Your version and Trans's example would work fine for very localized
> namespacing, which would have much lower implementation impact (and may
> also be useful).

I see the use of namespaces mostly in safe monkey patching. I.e. that I 
can change the behaviour of default .each for a namespace without 
breaking a library that depends on the default way .each works.

>> Also I fail to see how lookup would become more complicated. Take a look 
>> at the approach I took. I copy the classes (on interpreter level one 
>> could use COW techniques to reduce memory usage) into the new namespace. 
>> The numbers of levels to look a method up or the way to look it up does 
>> in no way change. Or do I miss something there?
> 
> The complication is that under normal circumstances a method has no
> knowledge of whether it's being called inside a namespace or not, since
> the installation of the namespace itself is just another method call. So
> every method in the system would have to check whether they are being
> called under a namespace.
> 
> Your code gets around that by essentially delaying the parse until a
> namespace is already installed. While this works, and allows namespacing
> within that subcontext, you lose all the benefits of having code only
> get parsed once. eval is *very* expensive, even more expensive than
> installing per-call namespace checks throughout the system.

Does that apply to block-eval too? That I currently have to resort to 
string-eval is only due to constant lookup rules, which with access to 
the interpreter could be changed. Or as somebody on irc mentioned, 
ruby2ruby could also be used to search constant lookup nodes and "bend" 
them.
Also isn't a required file essentially evaled too? Or are there 
differences I'm unaware of?

Regards
Stefan
-- 
Posted via http://www.ruby-forum.com/.