Hi,
while in the process of trimming down the failure rate of the
core/array specs I noticed a strange behavior of IronRuby. I’m pasting
here two repl sessions I used to reproduce it:
>>> foo = Object.new
=> #<Object:0x000005c>
>>> bar = Object.new
=> #<Object:0x000005e>
>>>
>>> def foo.to_s; p "foo#to_s has been invoked"; "foo" end;
=> nil
>>>
>>> foo
"foo#to_s has been invoked"
=> foo
>>> bar
=> #<Object:0x000005e>
As you can see there is nothing wrong here, so here is the second
session where the only difference is in that the order of foo and bar
at the end of the snippet is inverted:
>>> foo = Object.new
=> #<Object:0x000005c>
>>> bar = Object.new
=> #<Object:0x000005e>
>>>
>>> def foo.to_s; p "foo#to_s has been invoked"; "foo" end;
=> nil
>>>
>>> bar
=> #<Object:0x000005e>
>>> foo
=> #<Object:0x000005c>
I would expect to get “foo#to_s has been invoked” printed just like in
the first snippet (and IRB on MRI behave like expected), but instead
the method called on foo is the one of Object#to_s (a step-by-step
debug session confirmed this). Could it be related to some issues in
the method caching stuff that happens deep into the internals of
IronRuby?
This problem affects certain mocking scenarios when running mspec (eg.
“Array#== returns false if any element is not == to the corresponding
element in the other the array” and “Array#delete removes elements
that are #== to object”, but their implementation looks ok to me), so
it might even be possible that more specs which are being reported as
failures are not related to bogus implementations, but it is just
mspec that is failing due to a bug.
Is there anyone that can confirm this before I file a bug on the bug
tracker?
Thanks,
Daniele
–
Daniele A.
http://www.clorophilla.net/blog/
http://twitter.com/JoL1hAHN