7

Just realized that instance_eval yields self as an argument to the associated block (except for a bug in the 1.9.2 version: http://www.ruby-forum.com/topic/189422)

1.9.3p194 :003 > class C;end
1.9.3p194 :004 > C.new.instance_eval {|*a| a}
 => [#<C:0x00000001f99dd0>] 
1.9.3p194 :005 >

Is this documented/spec'ed somewhere? Looking at ruby-doc:BasicObject, can't see any block params mentioned.

Is there a reason -apart from some purely historical one- for passing it explicitly when it self is always defined anyway?

The way I was hit by this is:

l = lambda {  }
myobj.instance_eval(&l)  # barks

This worked fine in 1.8.x (I guess because of block arity wasn't enforced).

Then upgraded to 1.9.2 - and it still worked! That's a strange coincidence as even though lambda block arguments are strictly enforced (so it would have complained for not declaring the argument for self), however due to the bug linked above - the self actually wasn't passed in this version..

Then upgraded to 1.9.3 where that bug got fixed, so it started to throwing the argument error - pretty surprising for a minor version change IMHO.

So one workaround is do declare parameter, or make lambda a block instead:

 l = proc {  }
  myobj.instance_eval(&l) # fine

Just thought to describe the full story to help others avoid wasting time the way I did - until this is properly documented.

inger
  • 19,574
  • 9
  • 49
  • 54

3 Answers3

3

Reading Ruby's source code, what I can interpret is:

instance_eval is executing this:

return specific_eval(argc, argv, klass, self)

which in turn runs:

 if (rb_block_given_p()) {
     if (argc > 0) {
         rb_raise(rb_eArgError, "wrong number of arguments (%d for 0)", argc);
     }
     return yield_under(klass, self, Qundef);
 }

You can see they pass Qundef for the VALUES argument.

if (values == Qundef) {
    return vm_yield_with_cref(th, 1, &self, cref);
}

In that particular line of code, they set manually argc (argument count) to 1 and the argument as "self". Later on the code that prepares the block sets the arguments to the block to these arguments, hence the first argument = "self" and the rest are nil.

The code that sets up the block arguments is doing :

   arg0 = argv[0];

   ... bunch of code ...

     else {
         argv[0] = arg0;
     }

     for (i=argc; i<m; i++) {
         argv[i] = Qnil;
     }

Resulting in:

1.9.3p194 :006 > instance_eval do |x, y, z, a, b, c, d| x.class end
 => Object 
1.9.3p194 :008 > instance_eval do |x, y, z, a, b, c, d| y.class end
 => NilClass

Why ? I have no idea but the code seems to be intentional. Would be nice to ask the question to the implementers and see what they have to say about it.

[Edit]

This probably is like that because the blocks you pass to instance_eval may or may not be crafted for it (code that depends on self being set to the class you want the block to modify), instead they may assume you are going to pass them the instance you want them to modify as an argument and in this way they would work with instance_eval as well.

irb(main):001:0> blk = Proc.new do |x| x.class end
#<Proc:0x007fd2018447b8@(irb):1>
irb(main):002:0> blk.call
NilClass
irb(main):003:0> instance_eval &blk
Object

Of course this is only a theory and without official documentation I can only guess.

Francisco Soto
  • 10,277
  • 2
  • 37
  • 46
  • 1
    But we would still like to know whether this is documented somewhere, that self is also passed inside as an *argument*. – Boris Stitnicky Sep 28 '12 at 22:43
  • Well, the main effect of instance_eval is to set self=receiver_object, isnt' it? If the same object is passed (a[0] above), then will it always be 'self' won't it? So this sounds redundant to me, am I missing something - or are you misinterpreting the question as "what's the point of instance_eval". – inger Sep 28 '12 at 22:56
  • 1
    No, you are not. Indeed, the object is always available as self in the block and there is no need to pass it in as an argument. I don't think we are missing anything here, this is a bug. And upvote for Francisco for his analysis. – Boris Stitnicky Sep 29 '12 at 00:51
  • The 2nd version of your answer is definitely helpful. – inger Sep 29 '12 at 09:16
1

I have just dicovered that unlike #instance_eval, which is primarily intended for string evaluation, #instance_exec primarily intended for block evaluation, does not have the described behavior:

o = Object.new
o.instance_exec { |*a| puts "a.size is #{a.size}" }
  => a.size is 0

This is probably an unintended inconsistency, so you might have discovered a bug. Post it on Ruby bugs.

Boris Stitnicky
  • 12,444
  • 5
  • 57
  • 74
  • Except the arguments yielded to the block given to `instance_exec` *are* [documented](http://ruby-doc.org/core-1.9.3/BasicObject.html#method-i-instance_exec). – Andrew Marshall Sep 28 '12 at 23:58
  • Documented behavior of #instance_exec is not the point here, rather, presence or absence of undocumented behavior is discussed here. Also, make less assumptions about others, in particular, do not assume I have not read the complete available documentation before writing my answer. – Boris Stitnicky Sep 29 '12 at 00:43
  • Why should the documentation and behavior of one method be considered documentation for another? Just because `instance_exec` works one way doesn't mean `instance_eval` should too—and it certainly doesn't make it a bug. They're different methods after all. – Andrew Marshall Sep 29 '12 at 07:14
  • I agree 2 different methods different behaviour is not the bug itself (although I agree it can be seen as inconsistency and maybe violating the POLS). The real bug IMHO is undocumented behaviour which actually breaks certain use cases, then wasting time on debugging (unless you do want to look at the sources anyway). – inger Sep 29 '12 at 09:08
0

I just asked the same question here: Ruby lambda's proc's and 'instance_eval'

And after reading the answer and working through some code, I think I understand why ruby has this strange (IMHO) inconsistency.

It basically allows Symbol#to_proc to work.

For example ["foo", "bar"].each(&:puts) is short for [...].each { |x| puts x }

NOT

[...].each { self.puts }

So ruby also passes self as the first param to the proc, so basically the proc can either use self or its first param.

Since instance eval does not by definition explicitly pass params this is almost always invisible behavior.

The exception is when the proc is a lambda. This DOES NOT WORK:

2.4.1 :015 > foo = -> { puts 'hi' }
 => #<Proc:0x007fcb578ece78@(irb):15 (lambda)> 
2.4.1 :016 > [1, 2, 3].each(&foo)
ArgumentError: wrong number of arguments (given 1, expected 0)
    from (irb):15:in `block in irb_binding'
    from (irb):16:in `each'
    from (irb):16

So I think the only time this becomes a problem is when instance_eval is being used with some unknown value, where you don't know if the proc is a lambda or not. In this case you have to do it like this:

proc_var.lambda? ? instance_exec(&proc_var) : instance_eval(&proc_var)

Weird (to me) that ruby just does not do this under the hood for you.

but I guess you could make it so:

alias original_instance_eval instance_eval 
def instance_eval(*args, &block)
  block&.lambda? ? instance_exec(&block) : original_instance_eval(*args, &block)
end
Mitch VanDuyn
  • 2,838
  • 1
  • 22
  • 29