From: Rick DeNatale <rick.denatale@...>
Date: 2010-06-11T10:44:20+09:00
Subject: Re: Why private #binding?

On Thu, Jun 10, 2010 at 7:25 PM, Intransition <transfire@gmail.com> wrote:
>
>
> On Jun 10, 6:45 pm, Rick DeNatale <rick.denat...@gmail.com> wrote:

>> Here's a better example:
>>
>> def test(code)
>>   x = 1
>>   b = "abc".send(:binding)
>>   eval(code, b)
>> end
>>
>> test("self") # => "abc"
>> test("x")    # => 1
>>
>> The variable x has nothing to do with the string "abc".
>>
>> "abc".instance_eval  is a better choice if you want to bind self in an
>> evaluated string or block.
>
> But ERB needs a binding. And in almost every use of binding I have
> ever had it eds up coming from an external object. After all, it is
> rare one would need to use the binding from within the binding. I will
> often I make quick use of such a binding --form the place that it is
> created, but in the end I almost always move it to a separate scope so
> that I can strictly control what the eval sees.

I have to admit that you totally lost me in that last sentence, and
why it supports the argument to make Kernel#binding public.

> So I understand technically what you and matz are saying, but from a
> practical point a view I think #binding would be most useful if it was
> defined as something akin to:
>
>  def binding(locals={})
>    locals.each{|k,v| local_varaible_set(k,v) }
>    return binding
>  end

So what's so sacred about the method name, why not just take that idea
and add (not to standard Ruby but yourself)

module Kernel
   def to_binding(locals={})
      locals.each{|k,v| local_variable_set(k,v) }
      return binding
   end
end

or, following Matz' observation a better name might be to_eval_environment

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale