Yehuda Katz wrote: > Ok, based on a bunch of comments I got from Aaron Patterson and John > Barnette, a somewhat modified proposal: > > https://gist.github.com/83d390aea81a12f1667c I'm trying to work out the details in my head. The main complication I have is what gets done at parse time and what gets done at runtime. Parse Time: It seems like at least the "use" would have to set a global or per-thread flag during parsing so that calls made under that scope would be generated with extra logic for namespace checking. Runtime: The runtime bit is trickier. I think the node passed to use would have to be saved off in the parsed calls so they could do that lookup. But then there's the question of whether they should look it up each time. That's a constant lookup hit for ever namespaced call. Looking it up every time could also lead to some oddities if the method itself had conflicting constants in its lookup hierarchy. If instead the use itself were captured and used as the reference point for the the lookup, it would be executed once in the script, immediately cached, and all calls would then use the same value. Yes, I think that's probably better. So a NamespacedCallNode would aggregate a UseNode, with the UseNode aggregating some other node structure for the argument and a body of code; basically all calls would have a backreference to the 'use', and the 'use' itself would represent the cache key and lookup reference point. Threading: I lean more toward having the parse of a "use" set a flag in the executing parser instance on a single thread; there are possible complications here though. If one thread requires a file while in a "use", and at the same time another thread requires the same file without a "use", we have a race. If one thread requires a file and another file loads it, we have issues as well (though not substantially different from issues in normal Ruby. Of course the threading concerns are entirely parse-time; once parsed every thread would see the namespacing, eh? Mock-up: As this settles we could probably mock it up pretty easily in JRuby. My early attempt was without parser support; I could continue hacking it that way, but having real parser help would make it easier. We shall see...I'm curious what others think of the proposal. - Charlie