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. Cheers -- Ola Bini (http://olabini.com) Ioke creator (http://ioke.org) JRuby Core Developer (http://jruby.org) Developer, ThoughtWorks Studios (http://studios.thoughtworks.com) Practical JRuby on Rails (http://apress.com/book/view/9781590598818) "Yields falsehood when quined" yields falsehood when quined.