From: Adam Strzelecki <ono@...>
Date: 2009-04-15T19:06:12+09:00
Subject: Re: Proc.call with custom bindings

> I don't think so, and in the general case this would be very difficult 
> (e.g. it could change dynamically whether 'foo' represents a local 
> variable or a method call)

Yeah, I just got the same reply at Haml group on this subject. AFAIK 
this may be due locals in Ruby are optimized and not accessed by symbol 
but address (stack offset?), so injecting different locals would cause 
change in AST/VM code, which is no go for already compiled proc.

So think this explains my problem:
---- cut ----
proc = Proc.new do
  if defined? s
    puts "s = #{s}"
  else
    puts "s is undefined"
  end
end
proc.call
s = 1
proc.call
---- cut ----

We got twice "s is undefined" even it is defined at second call.

But here:
---- cut ----
s = 'a'
proc = Proc.new do
  if defined? s
    puts "s = #{s}"
  else
    puts "s is undefined"
  end
end
proc.call
s = 'b'
proc.call
---- cut ----
Defining s before defining proc, makes the local var alive and it is 
defined in both 2 calls, moreover we change its value! (s = 'b' at the 
second call)
So this is just the way Ruby works.

> See how Rails solves this problem:
http://github.com/rails/rails/blob/3c1187699a80e0c4a003f5693389595cd644390f/actionpack/lib/action_view/template/renderable.rb
> 
> Scroll down to the private 'def compile!' at the bottom.

Yeah this is it. This is same way Haml does inside 
Haml::Engine#render_proc I think I will stick to that method for optimal 
performance.

Best regards,
--
Adam
-- 
Posted via http://www.ruby-forum.com/.