S
Sam Aaron
Hi there,
I was wondering whether it would be possible for someone to spend a
moment
of their time to either answer my question, or point me in the right
direction regarding some interesting (to me) Ruby behaviour w.r.t.
Kernel#binding, Kernel#eval and ERB#result.
Here's an example class I knocked up to illustrate my findings:
class Cheese
def please_dont_burn_me!
#doesn't work
eval "stilton = 'tasty'"
puts "Stilton is " + stilton
end
def just_melted_is_best
#does work
eval "shropshire_blue = 'very tasty'"
eval "puts 'Shropshire Blue is ' + shropshire_blue"
end
def throw_cubes_in_the_air_and_catch_them_in_your_mouth
#again, doesn't work
eval "cheddar = 'the staple cheese'"
puts ERB.new("Cheddar is <%= cheddar %>").result
end
def grated_is_good
#passing it the current binding allows it to work
eval "brie = 'best consumed when warm and runny'"
puts ERB.new("Brie is <%= brie %>").result(binding)
end
end
I understand why Cheese#please_dont_burn_me! doesn't work; apparently
around Ruby 1.8 any assignments made within an eval aren't available
to the general context (following block-like semantics). However, this
doesn't seem to explain why Cheese#just_melted_is_best works. There is
similar behaviour with ERB#result; by explicitly passing the current
binding, the result method is able to see the variable cheddar.
Interestingly, when these examples are declared outside of an explicit
class declaration, we see slightly different behaviour:
#still doesn't work (as expected)
eval "stilton = 'tasty'"
puts "Stilton is " + stilton
#works
eval "shropshire_blue = 'very tasty'"
eval "puts 'Shropshire Blue is ' + shropshire_blue"
#this time it works...
eval "cheddar = 'the staple cheese'"
puts ERB.new("Cheddar is <%= cheddar %>").result
#works
eval "brie = 'best consumed when warm and runny'"
puts ERB.new("Brie is <%= brie %>").result(binding)
I guess my question is: is there an easy way of explaining and
understanding how bindings operate in these situations, or is the
answer just due to the quirks of the c implementation?
Yours,
Sam Aaron
I was wondering whether it would be possible for someone to spend a
moment
of their time to either answer my question, or point me in the right
direction regarding some interesting (to me) Ruby behaviour w.r.t.
Kernel#binding, Kernel#eval and ERB#result.
Here's an example class I knocked up to illustrate my findings:
class Cheese
def please_dont_burn_me!
#doesn't work
eval "stilton = 'tasty'"
puts "Stilton is " + stilton
end
def just_melted_is_best
#does work
eval "shropshire_blue = 'very tasty'"
eval "puts 'Shropshire Blue is ' + shropshire_blue"
end
def throw_cubes_in_the_air_and_catch_them_in_your_mouth
#again, doesn't work
eval "cheddar = 'the staple cheese'"
puts ERB.new("Cheddar is <%= cheddar %>").result
end
def grated_is_good
#passing it the current binding allows it to work
eval "brie = 'best consumed when warm and runny'"
puts ERB.new("Brie is <%= brie %>").result(binding)
end
end
I understand why Cheese#please_dont_burn_me! doesn't work; apparently
around Ruby 1.8 any assignments made within an eval aren't available
to the general context (following block-like semantics). However, this
doesn't seem to explain why Cheese#just_melted_is_best works. There is
similar behaviour with ERB#result; by explicitly passing the current
binding, the result method is able to see the variable cheddar.
Interestingly, when these examples are declared outside of an explicit
class declaration, we see slightly different behaviour:
#still doesn't work (as expected)
eval "stilton = 'tasty'"
puts "Stilton is " + stilton
#works
eval "shropshire_blue = 'very tasty'"
eval "puts 'Shropshire Blue is ' + shropshire_blue"
#this time it works...
eval "cheddar = 'the staple cheese'"
puts ERB.new("Cheddar is <%= cheddar %>").result
#works
eval "brie = 'best consumed when warm and runny'"
puts ERB.new("Brie is <%= brie %>").result(binding)
I guess my question is: is there an easy way of explaining and
understanding how bindings operate in these situations, or is the
answer just due to the quirks of the c implementation?
Yours,
Sam Aaron