[ruby-core:22509] Re: YASNP (Yet Another Selector Namespace Proposal)

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