Ola Bini wrote:
> Charles Oliver Nutter wrote:
>> Ola Bini wrote:
>>> I definitely like this thinking. As I see a selector proposal, it 
>>> basically works like this:
>>> every method call has an associated namespace. that namespace 
>>> defaults to the Parsing Default for that file.
>>> if a namespace is set for a file, then THAT namespace will be the 
>>> Parsing Default for that file.
>>> of course, this means that namespaces/selectors should just be names 
>>> - not modules.
>>
>> They certainly could be names, or the namespaces could be declared in 
>> a new way that the parser is more aware of. Using modules right now is 
>> mostly for convenience.
>>
>>> When you start having modules as namespaces, then it gets really 
>>> complicated to see what is actually scoped inside of another 
>>> namespace or not, since the parser can't know this.
>>
>> My prototype is basically just overloading modules to use as a method 
>> bag. In this sense it's similar to the "borrow" feature you added to 
>> JRuby to steal methods from a target module or class.
>>
>> As for the resolution of the namespace, I think doing it once when the 
>> "using" is encountered at runtime would work fine.
>>
>> - Charlie
>>
>>
> Well, my point was that in that case namespaces/selectors isn't strictly 
> a parse time feature, and as such will incur a cost on EVERY method call 
> in the lexical scope of a namespace - since you don't know which 
> CALL/FCALL/VCALL will actually resolve into something that is part of 
> the other namespace. Which means you'll have to create SEL_CALL nodes 
> for all CALL nodes inside of that lexical scope, since all can 
> potentially be a namespaced call. This will incur a heavy performance 
> cost which I think was one of the main objectives to avoid in the 
> original proposal.

Yes, sounds like you're thinking along the same lines I am..."SEL_CALL" 
node that knows how to do namespace searching in addition to type 
hierarchy searching.

I don't think it's that severe a cost...you just include a couple extra 
layers in the chain when searching for a target method to call. And for 
caching purposes, you would just check whether those layers have changed 
to invalidate a cache. So it would probably slightly slower than a 
non-namespaced call, but not by much. Certainly no worse than a slightly 
deeper hierarchy.

- Charlie