Digging Deeper

Here we look at important differences between block scoping in Ruby 1.8 and 1.9 and also learn about returning blocks from methods.

Returning Blocks from Methods

Earlier, I explained that blocks in Ruby may act as closures. A closure may be said to enclose the “environment” in which it is declared. Or, to put it another way, it carries the values of local variables from its original scope into a different scope. The example I gave previously showed how the block named ablock captures the value of the local variable x:

block_closure.rb

x = "hello world"
ablock = Proc.new { puts( x ) }

It is then able to “carry” that variable into a different scope. Here, for example, ablock is passed to aMethod. When ablock is called inside that method, it runs the code puts( x ). This displays “hello world” and not “goodbye”:

def aMethod( aBlockArg )
    x = "goodbye"
    aBlockArg.call            #=> "hello world"
end

In this particular example, this behavior may seem like a curiosity of no great interest. In fact, block/closures can be used more creatively.

For example, instead of creating a block and sending it to a method, you could create a block inside a method and return that block to the calling code. If the method in which the block is created happens to take an argument, the block could be initialized with that argument.

This gives you a simple way of creating multiple blocks from the same “block template,” each instance of which is initialized with different data. Here, for example, I have created two blocks and assigned them to the variables salesTax and vat, each of which calculates results based on different values (0.10) and (0.175):

block_closure2.rb

def calcTax( taxRate )
    return lambda{
        |subtotal|
            subtotal * taxRate
    }
end

salesTax = calcTax( 0.10 )
vat = calcTax( 0.175 )

print( "Tax due on book = ")
print( salesTax.call( 10 ) )       #=> 1.0

print( "
Vat due on DVD = ")
print( vat.call( 10 ) )            #=> 1.75

Blocks and Instance Variables

One of the less obvious features of blocks is the way in which they use variables. If a block may truly be regarded as a nameless function or method, then, logically, it should be able to contain its own local variables and have access to the instance variables of the object to which the block belongs.

Let’s look first at instance variables. Load the closures1.rb program. This provides another illustration of a block acting as a closure—by capturing the values of the local variables in the scope in which it was created. Here I have created a block using the lambda method:

closures1.rb

aClos = lambda{
    @hello << " yikes!"
}

This block appends the string “ yikes!” to the instance variable @hello. Notice that at this stage in the proceedings, no value has previously been assigned to @hello. I have, however, created a separate method, aFunc, which does assign a value to a variable called @hello:

def aFunc( aClosure )
    @hello = "hello world"
    aClosure.call
end

When I pass my block (the aClosure argument) to the aFunc method, the method brings @hello into being. I can now execute the code inside the block using the call method. And sure enough, the @hello variable contains the “hello world” string. The same variable can also be used by calling the block outside of the method. Indeed, now, by repeatedly calling the block, I will end up repeatedly appending the string “ yikes!” to @hello:

aFunc(aClos)      #<= @hello = "hello world yikes!"
aClos.call        #<= @hello = "hello world yikes! yikes!"
aClos.call        #<= @hello = "hello world yikes! yikes! yikes!"
aClos.call        # ...and so on

If you think about it, this is not too surprising. After all, @hello is an instance variable, so it exists within the scope of an object. When you run a Ruby program, an object called main is automatically created. So, you should expect any instance variable created within that object (the program) to be available to everything inside it.

The question now arises: What would happen if you were to send the block to a method of some other object? If that object has its own instance variable, @hello, which variable will the block use—the @hello from the scope in which the block was created or the @hello from the scope of the object in which the block is called? Let’s try that. You’ll use the same block as before, except this time it will display a bit of information about the object to which the block belongs and the value of @hello:

aClos = lambda{
    @hello << " yikes!"
    puts("in #{self} object of class #{self.class}, @hello = #{@hello}")
}

Now, create a new object from a new class (X), and give it a method that will receive the block b and call the block:

class X
    def y( b )
        @hello = "I say, I say, I say!!!"
        puts( "   [In X.y]" )
        puts("in #{self} object of class #{self.class}, @hello = #{@hello}")
        puts( "   [In X.y] when block is called..." )
        b.call
    end
end

x = X.new

To test it, just pass the block aClos to the y method of x:

x.y( aClos )

And this is what is displayed:

[In X.y]
in #<X:0x32a6e64> object of class X, @hello = I say, I say, I say!!!
    [In X.y] when block is called...
in main object of class Object, @hello = hello world yikes! yikes! yikes!
 yikes! yikes! yikes!

So, it is clear that the block executes in the scope of the object in which it was created (main) and retains the instance variable from that object even though the object in whose scope the block is called has an instance variable with the same name and a different value.

Blocks and Local Variables

Now let’s see how a block/closure deals with local variables. In the closures2.rb program, I declare a variable, x, which is local to the context of the program:

closures2.rb

x = 3000

The first block/closure is called c1. Each time I call this block, it picks up the value of x defined outside the block (3,000) and returns x + 100:

c1 = proc{
    x + 100
}

Incidentally, even though this returns a value (in ordinary Ruby methods, the default value is the result of the last expression to be evaluated), in Ruby 1.9 you cannot explicitly use the return statement here like this:

return x + 1

If you do this, Ruby 1.9 throws a LocalJumpError exception. Ruby 1.8, on the other hand, does not throw an exception.

This block has no block parameters (that is, there are no “block-local” variables between upright bars), so when it is called with a variable, someval, that variable is discarded, unused. In other words, c1.call(someval) has the same effect as c1.call().

So, when you call the block c1, it returns x+100 (that is, 3,100); this value is then assigned to someval. When you call c1 a second time, the same thing happens all over again, so once again someval is assigned 3,100:

someval=1000
someval=c1.call(someval); puts(someval)    #<= someval is now 3100
someval=c1.call(someval); puts(someval)    #<= someval is now 3100

2.times{ someval=c1.call(someval); puts(someval) }

However, because it can be hard enough to work out what just one block is up to (such as the c1 block here), I’ve deliberately avoided using any more blocks than are absolutely necessary in this program!

The second block is named c2. This declares the “block parameter” z. This too returns a value:

c2 = proc{
    |z|
    z + 100
}

However, this time the returned value can be reused since the block parameter acts like an incoming argument to a method—so when the value of someval is changed after it is assigned the return value of c2, this changed value is subsequently passed as an argument:

someval=1000
someval=c2.call(someval); puts(someval)      #<= someval is now 1100
someval=c2.call(someval); puts(someval)      #<= someval is now 1200

The third block, c3, looks, at first sight, pretty much the same as the second block, c2. In fact, the only difference is that its block parameter is called x instead of z:

c3 = proc{
    |x|
    x + 100
}

The name of the block parameter has no effect on the return value. As before, someval is first assigned the value 1,100 (that is, its original value, 1,000, plus the 100 added inside the block). Then, when the block is called a second time, someval is assigned the value 1,200 (its previous value, 1,100, plus 100 assigned inside the block).

But now look at what happens to the value of the local variable x. This was assigned 3,000 at the top of the unit. Remember that, in Ruby 1.8, an assignment to a block parameter can change the value of a variable with the same name in its surrounding context. In Ruby 1.8, then the local variable x changes when the block parameter x is changed. It now has the value, 1,100—that is, the value that the block parameter, x, last had when the c3 block was called:

x = 3000
someval=1000
someval=c3.call(someval); puts(someval)    #=> 1100
someval=c3.call(someval); puts(someval)    #=> 1200
puts( x ) # Ruby 1.8, x = 1100. Ruby 1.9, x = 3000

Incidentally, even though block-local variables and block parameters can affect similarly named local variables outside the block in Ruby 1.8, the block variables themselves have no “existence” outside the block. You can verify this using the defined? keyword to attempt to display the type of variable if it is, indeed, defined:

print("x=[#{defined?(x)}],z=[#{defined?(z)}]")

This demonstrates that only x, and not the block variable z, is defined in the main scope:

x=[local-variable], z=[]

Matz, the creator of Ruby, has described the scoping of local variables within a block as “regrettable.” Although Ruby 1.9 has addressed some issues, it is worth noting that one other curious feature of block scoping remains: Namely, local variables within a block are invisible to the method containing that block. This may be changed in future versions. For an example of this, look at this code:

local_var_scope.rb

def foo
    a = 100
    [1,2,3].each do |b|
        c = b
        a = b
        print("a=#{a}, b=#{b}, c=#{c}
")
    end
    print("Outside block: a=#{a}
")    # Can't print #{b} and #{c} here!!!
end

Here, the block parameter, b, and the block-local variable, c, are both visible only when inside the block. The block has access to both these variables and to the variable a (local to the foo method). However, outside of the block, b and c are inaccessible, and only a is visible.

Just to add to the confusion, whereas the block-local variable, c, and the block parameter, b, are both inaccessible outside the block in the previous example, they are accessible when you iterate a block with for, as in the following example:

def foo2
    a = 100
    for b in [1,2,3] do
        c = b
        a = b
        print("a=#{a}, b=#{b}, c=#{c}
")
    end
    print("Outside block: a=#{a}, b=#{b}, c=#{b}
")
end