From: Paul Brannan <pbrannan@...>
Date: 2007-12-27T05:03:23+09:00
Subject: Re: Some Ruby 1.9 loose ends to tie up

On Sat, Dec 22, 2007 at 10:21:35AM +0900, Charles Oliver Nutter wrote:
> SASADA Koichi wrote:
> >The reason why I commit Proc#binding is that some of applications
> >needs this feature such as template engine.  Some people asked me to
> >add it and matz admit it.  It seems reasonable reason.
> 
> The only thing it gains you is that you don't have to explicitly pass in 
> a binding. If those template engines just required you to pass in a 
> binding, there would be no problem removing Proc#binding.
> 
> But I digress...it's a fun feature, and some people want it. We'll 
> continue to support it, and people will pay a performance penalty as a 
> result. Those are the tradeoffs we all learn to accept. :)

Charlie and I were talking about this at Rubyconf.  It seems silly to me
that a method called like this:

  foo { }

can access the caller's local variables, but a method called like this:

  foo()

cannot.  It feels like taking advantage of an unintentional side-effect
of passing in a block.

I think a lot of this sort of magic would be a lot cleaner and more
easily optimizable if foo were a macro rather than a method call.

> JRuby "pretends" that eval, binding, and other methods are keywords, 
> since the only cases where they won't be their normal selves is if 
> they're aliased (which nobody does). Other methods in the system have 
> similar treatment. By assuming that "eval" always means eval, we can 
> optimize specific scopes to use Java stack for local variables.

Do you explicitly disallow aliasing these methods?

How would you handle this:

irb(main):001:0> o = Object.new
=> #<Object:0x40502f44>
irb(main):002:0> b = o.send(:binding)
=> #<Binding:0x404ff9ac>
irb(main):003:0> eval("o", b)
=> #<Object:0x40502f44>

If they eval and binding are keywords, I think this should fail.

> If eval, binding, etc, or a block are present, JRuby falls back on a 
> heap-based structure. If procs could not be bindings, we could fall back 
> for only specific variables, leaving the others on the stack (a 
> technique that IronRuby and XRuby use, but which will break in the 
> presence of proc-as-binding).

Which variables would need to be placed on the heap in this case?

Paul