Go! Go! Go!
I remember starting my journey with Ruby and seeing some code that looked a bit like this:
3.times { puts "Go!" }
Still today I look at the code and marvel at it. You know exactly what it's going to do.
And yet in this code that's fewer than 20 characters long, there's so much more joy to discover.
3 is a magic number just an object with methods
You'd be forgiven for glossing over the 3.times and not giving it a second thought – assuming it to be some kind of special syntax.
But when you do take that pause, and recall that in Ruby everything is an object, you can reason that 3 is an object (it's an instance of Integer) and therefore times must be a method available to instances of Integer.
And you can kinda prove that by rewriting the above in a (ridiculous) longer format where we find the method times on the instance of 3 and then call that method.
3.method(:times).call { puts "Go!" }
What's interesting about that verbose format, though, is the documentation for times becomes even clearer.
Calls the given block self times with each integer in (0..self-1)
Given that self is 3, and our verbose code actually uses the method call, we can be sure that { puts "Go!" } is the given block.
The block party
And what's a block? Well, it's just a block of code. This isn't a clever programming term; think of it like a block of cheese – it's just a name for an arbitrarily-sized chunk of something.
The curly braces signal the start and end of the block. And everything inside those curly braces is just ... more Ruby.
Blocks don't need a name, nor do they need to be defined or registered anywhere else.
In your blocks, you have access to variables provided to the them by the method.
The times method yields each integer to the block. So with 3.times we get 0, 1, and 2 given to each call of the block.
A transfer of control
If you look up synonyms for the word yield (and not in the crop sense) you will find "surrender".
So you can think of the times method surrendering control of each integer to the block of code.
But that's perhaps a negative way of looking things.
A more positive spin might lead you to conclude that when you pass a block of code to the times method, you get to supply the behaviour.
And that's still a bit of a "woah" statement to me.
So often we define behaviour in our methods and supply data to them. But this kinda inverts all that: instead we supply the behaviour to 3.times and it supplies the data (in the form of 0, 1, and 2).
And now things get odd
I use the word "supply" above, and perhaps that makes it sound like a block is passed as an argument to times.
But let's try look at the following:
3.times("hey")
# 💥 Our program blows up with something like this:
# in `times': wrong number of arguments (given 1, expected 0) (ArgumentError)
Which begs the question, if times expects zero arguments, how we can we supply it a block of code?
And the answer is – and you may want to be sitting down for this – that you can supply any method a block of code, but whether or not it does anything with that block is up to the method.
It's totally cool if you feel a bit dizzy right now. I've been writing Ruby for about 14 years, and only just managed to understand it enough to cobble this post together. But let's continue regardless.
def say_hello
puts "hello"
end
Above is a trivial method that you can define. It takes no arguments. It just outputs a string. Very dull. Maybe demure.
So what do you think happens if you call it like this?
say_hello { puts "goodbye" }
The answer is that it just puts "hello". But it does not blow up, because it does absolutely nothing with the block; just ignores it completely. Syntactically, it's absolutely fine.
This is both expected and unexpected. Expected in the sense that we never surrender (or yield) control to the block in our method definition – so it never has the opportunity to output "goodbye".
But it's also unexpected because ... well, it's just a bit weird, right?
With great weirdness comes great flexibility – or something like that. And because Ruby is kind enough to give us this ability to tack blocks on to the end of any method call, it also gives a way to check if the caller decided to accept our offer of passing a block.
Consider the following:
# A method that checks for a block
def maybe_i_get_a_block
if block_given?
yield
else
puts "No block given this time"
end
end
maybe_i_get_a_block
# Output: No block given this time
maybe_i_get_a_block { puts "You got a block!" }
# Output: You got a block!
So we can vary the behaviour of our methods based on whether a block is given. Which is exactly what Ruby's standard library does, too.
Which brings us back to where we began. When a block is supplied to times, it goes ahead and calls the block the given number of times – and then returns the integer. But when no block is supplied, we get back an Enumerator object.
3.times { puts "Go!" }
# returns 3 (after outputting "Go!" three times)
3.times
# returns an instance of Enumerator
A fair but incorrect assumption
So if 3.times returns an instance of Enumerator (a super-useful object that allows you to move through collections objects, but we can go deeper on that another day), and 3.times { puts "Go!" } outputs what we'd expect, then it stands to reason that we could just throw a block at an enumerator. Like so:
my_enumerator = 3.times
my_enumerator { puts "Go!" }
# 💥 Oh no, this blows up with the following
# undefined method 'my_enumerator' for main (NoMethodError)
I remember starting my journey with Ruby and seeing some code that looked a bit like this:
3.times { puts "Go!" }
Still today I look at the code and marvel at it. You know exactly what it's going to do.
And yet in this code that's fewer than 20 characters long, there's so much more joy to discover.
3 is a magic number just an object with methods
You'd be forgiven for glossing over the 3.times and not giving it a second thought – assuming it to be some kind of special syntax.
But when you do take that pause, and recall that in Ruby everything is an object, you can reason that 3 is an object (it's an instance of Integer) and therefore times must be a method available to instances of Integer.
And you can kinda prove that by rewriting the above in a (ridiculous) longer format where we find the method times on the instance of 3 and then call that method.
3.method(:times).call { puts "Go!" }
What's interesting about that verbose format, though, is the documentation for times becomes even clearer.
Calls the given block self times with each integer in (0..self-1)
Given that self is 3, and our verbose code actually uses the method call, we can be sure that { puts "Go!" } is the given block.
The block party
And what's a block? Well, it's just a block of code. This isn't a clever programming term; think of it like a block of cheese – it's just a name for an arbitrarily-sized chunk of something.
The curly braces signal the start and end of the block. And everything inside those curly braces is just ... more Ruby.
Blocks don't need a name, nor do they need to be defined or registered anywhere else.
In your blocks, you have access to variables provided to the them by the method.
The times method yields each integer to the block. So with 3.times we get 0, 1, and 2 given to each call of the block.
A transfer of control
If you look up synonyms for the word yield (and not in the crop sense) you will find "surrender".
So you can think of the times method surrendering control of each integer to the block of code.
But that's perhaps a negative way of looking things.
A more positive spin might lead you to conclude that when you pass a block of code to the times method, you get to supply the behaviour.
And that's still a bit of a "woah" statement to me.
So often we define behaviour in our methods and supply data to them. But this kinda inverts all that: instead we supply the behaviour to 3.times and it supplies the data (in the form of 0, 1, and 2).
And now things get odd
I use the word "supply" above, and perhaps that makes it sound like a block is passed as an argument to times.
But let's try look at the following:
3.times("hey")
# 💥 Our program blows up with something like this:
# in `times': wrong number of arguments (given 1, expected 0) (ArgumentError)
Which begs the question, if times expects zero arguments, how we can we supply it a block of code?
And the answer is – and you may want to be sitting down for this – that you can supply any method a block of code, but whether or not it does anything with that block is up to the method.
It's totally cool if you feel a bit dizzy right now. I've been writing Ruby for about 14 years, and only just managed to understand it enough to cobble this post together. But let's continue regardless.
def say_hello
puts "hello"
end
Above is a trivial method that you can define. It takes no arguments. It just outputs a string. Very dull. Maybe demure.
So what do you think happens if you call it like this?
say_hello { puts "goodbye" }
The answer is that it just puts "hello". But it does not blow up, because it does absolutely nothing with the block; just ignores it completely. Syntactically, it's absolutely fine.
This is both expected and unexpected. Expected in the sense that we never surrender (or yield) control to the block in our method definition – so it never has the opportunity to output "goodbye".
But it's also unexpected because ... well, it's just a bit weird, right?
With great weirdness comes great flexibility – or something like that. And because Ruby is kind enough to give us this ability to tack blocks on to the end of any method call, it also gives a way to check if the caller decided to accept our offer of passing a block.
Consider the following:
# A method that checks for a block
def maybe_i_get_a_block
if block_given?
yield
else
puts "No block given this time"
end
end
maybe_i_get_a_block
# Output: No block given this time
maybe_i_get_a_block { puts "You got a block!" }
# Output: You got a block!
So we can vary the behaviour of our methods based on whether a block is given. Which is exactly what Ruby's standard library does, too.
Which brings us back to where we began. When a block is supplied to times, it goes ahead and calls the block the given number of times – and then returns the integer. But when no block is supplied, we get back an Enumerator object.
3.times { puts "Go!" }
# returns 3 (after outputting "Go!" three times)
3.times
# returns an instance of Enumerator
A fair but incorrect assumption
So if 3.times returns an instance of Enumerator (a super-useful object that allows you to move through collections objects, but we can go deeper on that another day), and 3.times { puts "Go!" } outputs what we'd expect, then it stands to reason that we could just throw a block at an enumerator. Like so:
my_enumerator = 3.times
my_enumerator { puts "Go!" }
# 💥 Oh no, this blows up with the following
# undefined method 'my_enumerator' for main (NoMethodError)