From: SASADA Koichi <ko1@...>
Date: 2007-12-22T09:48:02+09:00
Subject: Re: Some Ruby 1.9 loose ends to tie up

Hi,

Charles Oliver Nutter wrote:
> Yukihiro Matsumoto wrote:
>> |1) Will Proc.binding be made to work in 1.9?
>>
>> Just done.
> 
> I would like to hear from Koichi how this affects various optimizations
> we talked about at RubyConf. Specifically, in JRuby, the ability to turn
> a proc into a binding means that all scopes with a block in them must
> use a (slower) heap-based local variable store rather than a (faster)
> stack-based store. However Ruby 1.9 has more control over the stack, so
> perhaps it's not as difficult to pull it into a heap structure.

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.

I can't say anything that Proc#binding should be or should not be
removed for JRuby's performance.  As a ruby user, I think it should
be supported.  As a VM implementator, I think it (and other dynamic
features) should be vanished.

On optimization aspect, I believe that we can't optimize environment
if Kernel.binding and Kernel.eval are normal methods.

But on JRuby, just now I understand that JVM stack holds (will
hold?) ruby's environment (local variables and so on).


> Beyond implementation details, I still think it's a problematic feature
> that breaks encapsulation of the caller's local variables. I don't like
> the idea that some API I call with a block can then modify my local
> vars...it has the same feel as retry-outside-rescue did.

Some people wish it as binding of caller.  In fact, debugger needs it.

-- 
// SASADA Koichi at atdot dot net