From: Ola Bini Date: 2009-02-26T06:41:43+09:00 Subject: [ruby-core:22516] Re: YASNP (Yet Another Selector Namespace Proposal) Charles Oliver Nutter wrote: > Ola Bini wrote: >> I have read the full thread now, and have some concrete questions >> about the proposal. I'm not opposed to the proposal, but these are >> things I'd really like to understand before agreeing to it. >> If any of this has been answered, or if I misunderstood something, I >> apologize in advance: > > And these are my opinions... > >> - How would this interact with send? > > I think it would be tricky to make it work with send unless send were > officially elevated in status a bit. Namespaces would not effect > "secondary calls" made by methods I directly call, and I consider > send's eventual invocation of a real target method to be a "secondary > call". > > In order for send to work, we'd have to special-case "send" behavior > to also know about namespaces active in the caller's scope. And I > think I've made it clear how I feel about caller-scoped data being > implicitly accessible for *any* purpose. Not only is it a real pain to > implement and optimize, it leads to greater complexity of the system > overall. And if that's not enough...it grants yet another special > behavior to core methods that's impossible to emulate with normal Ruby > code. That's bad. > >> - How would it interact with other introspection facilities? >> Kernel#method ? >> Basically, what is the runtime behavior of all metaprogramming >> and introspection features here... > > I would imagine you'd want introspection APIs for "in effect" > namespaces, but I don't see that normal introspection of a target > class would produce different results. At least in my understanding of > this, the namespace is really a transparent layer on top of the call > protocol...not on top of the target type. You might liken it to > Groovy's categories, but without the messy downstream threading effects. > > Of course, we could be describing different proposals here. As much as > I support Matz taking an implementation-agnostic approach to new > features, we do need to be able to implement those features *somehow* > and I don't see a clean way to do so with support for send and > introspection at the moment. > >> - Do I understand correctly that this is supposed to be a lexical >> effect, and not a dynamic one? > > Yes. Lexical and largely bound up at parse time. But how does the > parser know about runtime structures? ..... > >> ... in that case I have no idea how it's supposed to work at parse >> time. Basically, if you use modules as possible namespaces, there is >> no way the parser can know which methods are supposed to be possibly >> selector-based. And even so, you don't actually know in the above >> example that "str" is a String, so how do you know that Merb::String >> should be applied to that variable at parse time? The thread has said >> it's a lexical effect, but all the examples I see have confused >> lexical and dynamic effects, and parse time with runtime. > > My prototype doesn't do it yet, but I would see a real implementation > using whatever a namespace resolves to at the point which "using" > lives in the code, so usually at top-level. > > So at parse time: > > 1. The "using" is encountered, and the "locator" for the namespace is > saved at that point in the list of active namespaces > 2. The list of active namespaces is from then on attached to parsed > calls, possibly by adding new node types to avoid encumbering existing > call logic with namespace behavior. > > > At runtime: > > 1. The using is encountered during execution, and the locator is > fired. From then on that locator points to a single namespace and is > not reevaluated. > 2. The locators attached to methods later in that file are then > pre-populated with an appropriate namespace, and do not re-execute the > locator. > 3. The namespaced methods then would all be guaranteed to use the same > namespace for calls. > > There's no way to have it all be parse time since Ruby does not > support static declarations of modules or classes. And there's no way > to make it all at runtime without a large penalty, since all calls > would have to always be checking for namespaces, even in the majority > of code that doesn't use them. > > Have a look at the patch; since you're familiar with JRuby it might > explain a bit about it. Note that I'm reevaluating the "locator" for > the namespace every time, but that's easily fixed. > > - Charlie > > Thanks Charles, I think I've gotten most of my questions answered to some degree now. There is definitely some varying opinions on how to do things, but now I see how this could be done. I will crawl back under my rock now. 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.