I would like to use RSpec to ensure that my enumerable class is compatible with Ruby's visitor pattern:
# foo.rb
class Foo
def initialize(enum)
#enum = enum
end
include Enumerable
def each(&block)
#enum.each(&block)
end
end
Here is my rspec file:
# spec/foo_spec.rb
require 'rspec'
require './foo.rb'
describe Foo do
let(:items) { [1, 2, 3] }
describe '#each' do
it 'calls the given block each time' do
block = proc { |x| x }
block.should_receive(:call).exactly(items.size).times
Foo.new(items).each(&block)
end
end
end
But surprisingly, my examples fail when run (with rspec v2.14.5):
# $ bundle exec rspec
Failures:
1) Foo#each calls the given block each time
Failure/Error: block.should_receive(:call).exactly(items.size).times
(#<Proc:0x007fbabbdf3f90#/private/tmp/rspec-mystery/spec/foo_spec.rb:8>).call(any args)
expected: 3 times with any arguments
received: 0 times with any arguments
# ./spec/foo_spec.rb:12:in `block (3 levels) in <top (required)>'
Finished in 0.00082 seconds
1 example, 1 failure
Failed examples:
rspec ./spec/foo_spec.rb:11 # Foo#each calls the given block each time
Even more surprising, the class itself behaves exactly as I expect when used via ruby/irb:
# $ irb -r ./foo.rb
1.9.3-p125 :002 > f = Foo.new [1, 2, 3]
=> #<Foo:0x007ffda4059f70 #enum=[1, 2, 3]>
1.9.3-p125 :003 > f.each
=> #<Enumerator: [1, 2, 3]:each>
1.9.3-p125 :004 > block = proc { |x| puts "OK: #{x}" }
=> #<Proc:0x007ffda483fcd0#(irb):4>
1.9.3-p125 :005 > f.each &block
OK: 1
OK: 2
OK: 3
=> [1, 2, 3]
Why doesn't RSpec notice that the "block" does in fact receive the "call" message three times?
Why doesn't RSpec notice that the "block" does in fact receive the "call" message three times?
Because, AFAICT, on MRI, it doesn't.
#each isn't provided by Enumerable, only by the classes that implement it, and in your test, you're using an Array.
Here's the source code (in C) from Array#each:
VALUE rb_ary_each(VALUE array)
{
long i;
volatile VALUE ary = array;
RETURN_SIZED_ENUMERATOR(ary, 0, 0, rb_ary_length);
for (i=0; i<RARRAY_LEN(ary); i++) {
rb_yield(RARRAY_PTR(ary)[i]);
}
return ary;
}
From this, it looks like Array#each yields to the block rather than calling it explicitly.
UPDATE:
Your code & test fails on Rubinius & JRuby as well, so it looks like their standard libraries don't use call here either. As #mechanicalfish points out, you really only need to test that the iterator goes over the collection the correct number of times.
Blocks are not turned into Procs before being yielded to in MRI, per Matz's comment at https://www.ruby-forum.com/topic/71221, so it's understandable that they don't receive a :call as part of the yield process. Further, I don't believe there is any way to set expectations on a block, per se, as there is no way to reference a block as an object in the Ruby language.
You can, however, set expectations on Procs that they will receive the :call message and things will behave as you would expect.
Related
A basic example of what is confusing me:
def [](row, col)
self[row][col]
end
x = [[1,3], [4,5]]
x[0][0] #normal
x[0, 0] #syntactic sugar?
I have been told that these are equivalent statements, but when I run the sugar one, I get a different answer. How am I supposed to write it in syntactic sugar?
You need to put your def [](row, col) method in a class that contains your data. So something like:
$ irb
2.3.0 :001 > class MyData
2.3.0 :002?> attr_accessor :my_array
2.3.0 :003?> def [](row, col)
2.3.0 :004?> my_array[row][col]
2.3.0 :005?> end
2.3.0 :006?> end
=> :[]
2.3.0 :007 > x = MyData.new
=> #<MyData:0x007f96dc8024b8>
2.3.0 :008 > x.my_array = [[1, 3], [4, 5]]
=> [[1, 3], [4, 5]]
2.3.0 :009 > x[1,1]
=> 5
2.3.0 :010 >
There are two problems with this:
You are adding your method to the Object class. But Array has its own [] which overrides the one in Object, so your method never gets called …
… which is a good thing, because it doesn't work anyway: all the method does is call itself, that would lead to a stackoverflow because of runaway recursion, but thankfully, the method calls itself with one argument, but is defined to take two parameters, and thus all you get is an ArgumentError.
Now, forgetting for a moment that monkey patching a core class is a terrible idea, you could to this:
module TwoDArrayExtension
def [](x, y)
super(x).method(__callee__).super_method.(y)
end
end
class Array
prepend TwoDArrayExtension
end
x = [[1, 3], [4, 5]]
x[0][0] #normal
# in `[]': wrong number of arguments (given 1, expected 2) (ArgumentError)
# Hey, we just re-defined [] to take two arguments, so obviously this cannot work!
x[0, 0] #syntactic sugar?
#=> 1
This "works" in the sense that it gets your syntactic sugar example to pass. But your "normal" example now breaks: you have re-defined how arrays work, so you can no longer use it like an array. Tinkering with core classes like this has serious ramifications. For example:
Irb is written in Ruby, and uses arrays internally, among other things. You cannot test your code in Irb, because it will just crash.
The same applies to Pry.
The same applies to any and all existing code that uses arrays … which is pretty much all Ruby code ever written. You cannot use any gems. You cannot use and standard libraries.
In fact, in an implementation like Rubinius, where pretty much everything, including large parts of the core libraries themselves, and even the compiler are written in Ruby and thus use arrays internally, you probably won't even be able to get your code to run at all.
In short: yes, you can do this, but you really, really, really, REALLY don't want to.
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.
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.
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.
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
I am working on a gem that can uses different version of Gherkin, but I'm facing a problem:
in the 2.4.0 version Gherkin::Formatter::Model::Scenario.new takes 6 arguments but in 2.6.5 it takes 7 arguments.
So my question is what is a best practice in this case ? Should I do:
case Gherkin::Version
when '2.4.0'
do the init with 6 arguments
else
with the 7
end
I was thinking also of creating a new_with_arity method:
class Object
def new_with_arity(*params)
puts method(:initialize).arity # => -1
puts method(:new).arity # => -1
new(*(params + [nil] * (params.count - method(:new).arity)))
end
end
However this does not work, the arity of new and initialize is -1.
Do you have an idea ?
I would recommend following Jim Deville's advice. Saying that it's quite an interesting idea and you were pretty close. The problem is you can't get the method without having an instance, so the trick is to use allocate first.
class Object
def new_with_arity(*params)
new *(params + [nil] * (allocate.method(:initialize).arity - params.size))
end
end
class One
def initialize a
[a]
end
end
class Two
def initialize a, b
[a, b]
end
end
One.new_with_arity 1 #=> [1]
Two.new_with_arity 1, 2 #=> [1, 2]
Two.new_with_arity 1 #=> [1, nil]
I would build 2 Gherkin adapters and load up the proper one for the proper version. Or, you are using Rubygems, so you can force a specific version of the Gherkin parser
I just had a quick question regarding loops in Ruby. Is there a difference between these two ways of iterating through a collection?
# way 1
#collection.each do |item|
# do whatever
end
# way 2
for item in #collection
# do whatever
end
Just wondering if these are exactly the same or if maybe there's a subtle difference (possibly when #collection is nil).
This is the only difference:
each:
irb> [1,2,3].each { |x| }
=> [1, 2, 3]
irb> x
NameError: undefined local variable or method `x' for main:Object
from (irb):2
from :0
for:
irb> for x in [1,2,3]; end
=> [1, 2, 3]
irb> x
=> 3
With the for loop, the iterator variable still lives after the block is done. With the each loop, it doesn't, unless it was already defined as a local variable before the loop started.
Other than that, for is just syntax sugar for the each method.
When #collection is nil both loops throw an exception:
Exception: undefined local variable or method `#collection' for main:Object
See "The Evils of the For Loop" for a good explanation (there's one small difference considering variable scoping).
Using each is considered more idiomatic use of Ruby.
Your first example,
#collection.each do |item|
# do whatever
end
is more idiomatic. While Ruby supports looping constructs like for and while, the block syntax is generally preferred.
Another subtle difference is that any variable you declare within a for loop will be available outside the loop, whereas those within an iterator block are effectively private.
One more different..
number = ["one", "two", "three"]
=> ["one", "two", "three"]
loop1 = []
loop2 = []
number.each do |c|
loop1 << Proc.new { puts c }
end
=> ["one", "two", "three"]
for c in number
loop2 << Proc.new { puts c }
end
=> ["one", "two", "three"]
loop1[1].call
two
=> nil
loop2[1].call
three
=> nil
source: http://paulphilippov.com/articles/enumerable-each-vs-for-loops-in-ruby
for more clear: http://www.ruby-forum.com/topic/179264#784884
Never ever use for it may cause almost untraceable bugs.
Don't be fooled, this is not about idiomatic code or style issues. Ruby's implementation of for has a serious flaw and should not be used.
Here is an example where for introduces a bug,
class Library
def initialize
#ary = []
end
def method_with_block(&block)
#ary << block
end
def method_that_uses_these_blocks
#ary.map(&:call)
end
end
lib = Library.new
for n in %w{foo bar quz}
lib.method_with_block { n }
end
puts lib.method_that_uses_these_blocks
Prints
quz
quz
quz
Using %w{foo bar quz}.each { |n| ... } prints
foo
bar
quz
Why?
In a for loop the variable n is defined once and only and then that one definition is use for all iterations. Hence each blocks refer to the same n which has a value of quz by the time the loop ends. Bug!
In an each loop a fresh variable n is defined for each iteration, for example above the variable n is defined three separate times. Hence each block refer to a separate n with the correct values.
It looks like there is no difference, for uses each underneath.
$ irb
>> for x in nil
>> puts x
>> end
NoMethodError: undefined method `each' for nil:NilClass
from (irb):1
>> nil.each {|x| puts x}
NoMethodError: undefined method `each' for nil:NilClass
from (irb):4
Like Bayard says, each is more idiomatic. It hides more from you and doesn't require special language features.
Per Telemachus's Comment
for .. in .. sets the iterator outside the scope of the loop, so
for a in [1,2]
puts a
end
leaves a defined after the loop is finished. Where as each doesn't. Which is another reason in favor of using each, because the temp variable lives a shorter period.
(1..4).each { |i|
a = 9 if i==3
puts a
}
#nil
#nil
#9
#nil
for i in 1..4
a = 9 if i==3
puts a
end
#nil
#nil
#9
#9
In 'for' loop, local variable is still lives after each loop. In 'each' loop, local variable refreshes after each loop.
As far as I know, using blocks instead of in-language control structures is more idiomatic.
I just want to make a specific point about the for in loop in Ruby. It might seem like a construct similar to other languages, but in fact it is an expression like every other looping construct in Ruby. In fact, the for in works with Enumerable objects just as the each iterator.
The collection passed to for in can be any object that has an each iterator method. Arrays and hashes define the each method, and many other Ruby objects do, too. The for/in loop calls the each method of the specified object. As that iterator yields values, the for loop assigns each value (or each set of values) to the specified variable (or variables) and then executes the code in body.
This is a silly example, but illustrates the point that the for in loop works with ANY object that has an each method, just like how the each iterator does:
class Apple
TYPES = %w(red green yellow)
def each
yield TYPES.pop until TYPES.empty?
end
end
a = Apple.new
for i in a do
puts i
end
yellow
green
red
=> nil
And now the each iterator:
a = Apple.new
a.each do |i|
puts i
end
yellow
green
red
=> nil
As you can see, both are responding to the each method which yields values back to the block. As everyone here stated, it is definitely preferable to use the each iterator over the for in loop. I just wanted to drive home the point that there is nothing magical about the for in loop. It is an expression that invokes the each method of a collection and then passes it to its block of code. Hence, it is a very rare case you would need to use for in. Use the each iterator almost always (with the added benefit of block scope).
I'm new to Ruby, and I'm trying the following:
mySet = numOfCuts.times.map{ rand(seqLength) }
but I get the 'yield called out of block' error. I'm not sure what his means. BTW, this question is part of a more general question I asked here.
The problem is that the times method expects to get a block that it will yield control to. However you haven't passed a block to it. There are two ways to solve this. The first is to not use times:
mySet = (1..numOfCuts).map{ rand(seqLength) }
or else pass a block to it:
mySet = []
numOfCuts.times {mySet.push( rand(seqLength) )}
if "numOfCuts" is an integer,
5.times.foo
is invalid
"times" expects a block.
5.times{ code here }
You're combining functions that don't seem to make sense -- if numOfCuts is an integer, then just using times and a block will run the block that many times (though it only returns the original integer:
irb(main):089:0> 2.times {|x| puts x}
0
1
2
map is a function that works on ranges and arrays and returns an array:
irb(main):092:0> (1..3).map { |x| puts x; x+1 }
1
2
3
[2, 3, 4]
I'm not sure what you're trying to achieve with the code - what are you trying to do? (as opposed to asking specifically about what appears to be invalid syntax)
Bingo, I just found out what this is. Its a JRuby bug.
Under MRI
>> 3.times.map
=> [0, 1, 2]
>>
Under JRuby
irb(main):001:0> 3.times.map
LocalJumpError: yield called out of block
from (irb):2:in `times'
from (irb):2:in `signal_status'
irb(main):002:0>
Now, I don't know if MRI (the standard Ruby implementation) is doing the right thing here. It probably should complain that this does not make sense, but when n.times is called in MRI it returns an Enumerator, whereas Jruby complains that it needs a block.
Integer.times expects a block. The error message means the yield statement inside the times method can not be called because you did not give it a block.
As for your code, I think what you are looking for is a range:
(1..5).map{ do something }
Here is thy rubydoc for the Integer.times and Range.