Why private #binding?

ruby-talk
1

Why is #binding a private method? I end up doing a lot of this:

  class Scope
    def __binding__
      binding
    end
  end

In order to setup a scope for ERB evaluation, among other uses.

2

I can think of two potential reasons.

1. Because binding exposes the internals of the receiver.

2. because if it were public then in a case like:

class A
    def self.binding_of(b)
        b.binding
    end
end

A.binding_of("abc")

might well return a binding with self == A, rather than the string,
because binding returns the bindings "at the point of call"

···

On Thu, Jun 10, 2010 at 12:38 AM, Intransition <transfire@gmail.com> wrote:

Why is #binding a private method? I end up doing a lot of this:

class Scope
def __binding__
binding
end
end

In order to setup a scope for ERB evaluation, among other uses.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

3

Hi,

···

In message "Re: Why private #binding?" on Thu, 10 Jun 2010 22:29:32 +0900, Rick DeNatale <rick.denatale@gmail.com> writes:

I can think of two potential reasons.

1. Because binding exposes the internals of the receiver.

2. because if it were public then in a case like:

class A
   def self.binding_of(b)
       b.binding
   end
end

A.binding_of("abc")

might well return a binding with self == A, rather than the string,
because binding returns the bindings "at the point of call"

The latter one was the biggest reason for me.

              matz.

4

Knowing you, I suspected that that was the case. It would be for me as well.

···

On Thu, Jun 10, 2010 at 1:01 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Hi,

In message "Re: Why private #binding?" > on Thu, 10 Jun 2010 22:29:32 +0900, Rick DeNatale <rick.denatale@gmail.com> writes:

>I can think of two potential reasons.
>
>1. Because binding exposes the internals of the receiver.
>
>2. because if it were public then in a case like:
>
>
>class A
> def self.binding_of(b)
> b.binding
> end
>end
>
>A.binding_of("abc")
>
>might well return a binding with self == A, rather than the string,
>because binding returns the bindings "at the point of call"

The latter one was the biggest reason for me.

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

5

It doesn't recognize it's receiver?

···

On Jun 10, 1:01 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:

Hi,

In message "Re: Why private #binding?" > on Thu, 10 Jun 2010 22:29:32 +0900, Rick DeNatale <rick.denat...@gmail.com> writes:

>I can think of two potential reasons.
>
>1. Because binding exposes the internals of the receiver.
>
>2. because if it were public then in a case like:
>
>
>class A
> def self.binding_of(b)
> b.binding
> end
>end
>
>A.binding_of("abc")
>
>might well return a binding with self == A, rather than the string,
>because binding returns the bindings "at the point of call"

The latter one was the biggest reason for me.

6

Hi,

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.

···

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

7

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.

···

On Thu, Jun 10, 2010 at 5:08 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Hi,

In message "Re: Why private #binding?" > on Fri, 11 Jun 2010 04:57:32 +0900, Intransition <transfire@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\.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

8

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.

···

On Jun 10, 6:45 pm, Rick DeNatale <rick.denat...@gmail.com> wrote:

On Thu, Jun 10, 2010 at 5:08 PM, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> Hi,

> In message "Re: Why private #binding?" > > on Fri, 11 Jun 2010 04:57:32 +0900, Intransition <transf...@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.

9

Hi,

···

In message "Re: Why private #binding?" on Fri, 11 Jun 2010 08:25:28 +0900, Intransition <transfire@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.

10

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

···

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:

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

11

Is it truly different? How does one get restricted eval environment
without binding?

···

On Jun 10, 8:25 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:

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

12

Hi,

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

Is it truly different? How does one get restricted eval environment
without binding?

At least, you don't want some part of the current binding attributes.
You are free to use binding to implement restricted eval environment,
but if you want to change the binding behavior, it's different story.
Right now, I don't feel making it public is worth changing, when you
can define a small function to create binding for restricted
environment.

              matz.

···

In message "Re: Why private #binding?" on Fri, 11 Jun 2010 11:27:19 +0900, Intransition <transfire@gmail.com> writes:

13

Which is what I suggested. That's the beauty of Ruby, a programmer can
extend it without having to change it for the rest of us.

···

On Fri, Jun 11, 2010 at 4:32 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Hi,

In message "Re: Why private #binding?" > on Fri, 11 Jun 2010 11:27:19 +0900, Intransition <transfire@gmail.com> writes:

>> Probably you want something different from binding, maybe restricted
>> eval environment, do you?
>
>Is it truly different? How does one get restricted eval environment
>without binding?

At least, you don't want some part of the current binding attributes.
You are free to use binding to implement restricted eval environment,
but if you want to change the binding behavior, it's different story.
Right now, I don't feel making it public is worth changing, when you
can define a small function to create binding for restricted
environment.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale