Prev: weird action of 'nokogiri' library on Snow Leopard
Next: How to implement fork cocept in ruby
From: Yukihiro Matsumoto on 10 Jun 2010 17:08
Hi,

In message "Re: Why private #binding?"
on Fri, 11 Jun 2010 04:57:32 +0900, Intransition <transfire(a)gmail.com> writes:

|It doesn't recognize it's receiver?

binding returns the binding object that has info on

* the receiver
* local variables
* etc.

but invoking it from public form does not explain the context except
for the receiver.

matz.

From: Rick DeNatale on 10 Jun 2010 18:45
On Thu, Jun 10, 2010 at 5:08 PM, Yukihiro Matsumoto <matz(a)ruby-lang.org> wrote:
> Hi,
>
> In message "Re: Why private #binding?"
>    on Fri, 11 Jun 2010 04:57:32 +0900, Intransition <transfire(a)gmail.com> writes:
>
> |It doesn't recognize it's receiver?
>
> binding returns the binding object that has info on
>
>  * the receiver
>  * local variables
>  * etc.
>
> but invoking it from public form does not explain the context except
> for the receiver.
>
>                                                        matz.

Yes, actually my initial thought about self was the only thing that a
non-private binding method would get 'right'.

The real issue, I think, is that objects in general don't have
bindings, invocations do. Making Kernel#binding private means that
unless you resort to trickery, it will only occur in the context of an
invocation.

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.
--
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

From: Intransition on 10 Jun 2010 19:25


On Jun 10, 6:45 pm, Rick DeNatale <rick.denat...(a)gmail.com> wrote:
> On Thu, Jun 10, 2010 at 5:08 PM, Yukihiro Matsumoto <m...(a)ruby-lang.org> wrote:
> > Hi,
>
> > In message "Re: Why private #binding?"
> >    on Fri, 11 Jun 2010 04:57:32 +0900, Intransition <transf...(a)gmail.com> writes:
>
> > |It doesn't recognize it's receiver?
>
> > binding returns the binding object that has info on
>
> >  * the receiver
> >  * local variables
> >  * etc.
>
> > but invoking it from public form does not explain the context except
> > for the receiver.
>
> >                                                        matz.
>
> Yes, actually my initial thought about self was the only thing that a
> non-private binding method would get 'right'.
>
> The real issue, I think, is that objects in general don't have
> bindings, invocations do. Making Kernel#binding private means that
> unless you resort to trickery, it will only occur in the context of an
> invocation.
>
> 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.

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

Such that if binding is called without an explicit receiver, it
behaves at it does now, but with one as above. As it stands no one
every uses binding with a receiver b/c it's meaningless.

From: Yukihiro Matsumoto on 10 Jun 2010 20:25
Hi,

In message "Re: Why private #binding?"
on Fri, 11 Jun 2010 08:25:28 +0900, Intransition <transfire(a)gmail.com> writes:

|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.

Probably you want something different from binding, maybe restricted
eval environment, do you?

matz.

From: Rick DeNatale on 10 Jun 2010 21:44
On Thu, Jun 10, 2010 at 7:25 PM, Intransition <transfire(a)gmail.com> wrote:
>
>
> On Jun 10, 6:45 pm, Rick DeNatale <rick.denat...(a)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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: weird action of 'nokogiri' library on Snow Leopard
Next: How to implement fork cocept in ruby