Hacker News Reader

Comment by tcopeland | Hacker News Reader

I am still surprised by this behavior change from 2.2.3 to 2.3.0 (and also present in 2.3.1 and 2.4.0):

  $ ./ruby -e "puts RUBY_DESCRIPTION ; rand(BasicObject.new)"
  ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin14]
  -e:1:in `rand': undefined method `begin' for #<BasicObject:0x007fe0be4cb548> (NoMethodError)
	from -e:1:in `<main>'

In 2.2.3 you get this, which I'd expect:

  $ ./ruby -e "puts RUBY_DESCRIPTION ; rand(BasicObject.new)"
  ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin14]
  -e:1:in `rand': undefined method `respond_to?' for #<BasicObject:0x007fa2d719bf78> (NoMethodError)
	from -e:1:in `<main>'

It's as if rb_obj_respond_to changed... I don't understand it.

View on HN

I think you're looking in the wrong place, `BasicObject` has no `respond_to?` so you'd need to trace the `rand_random` execution to see what ends up calling `respond_to?` on your `BasicObject` instance. Poking through github I'm guessing it's `rb_funcallv_public` but I may be missing something(s).

But that's just it; I would have thought the NoMethodError would have been around the missing "respond_to?" - like it was in 2.2.3 - not around a missing "begin".

Like @tvon, I'm not up to digging through the code, but I'd guess it's falling through to eventually make an unconditional call to http://ruby-doc.org/core-2.3.0/Range.html#method-i-begin.

That's exactly right; but that's happening because vm_respond_to is returning true on a nil method entry. It's a puzzler...

I assume you mean at https://github.com/ruby/ruby/blob/v2_3_0/vm_method.c#L1915-L.... Agreed it's weird that rb_respond_to will now return true for objects where respond_to is undefined. Though I guess I can see upsides to doing so, and it would require something pretty weird to result in "wrong" behavior.

Yup that's the code that I'm wondering about.

The case I ran into was in a Rails 4.1 app where ActiveSupport::Duration (which subclassed BasicObject) was used like this: "rand(10.minutes)". That raised an exception in 2.3.0 but worked fine in 2.2.3. The fix was simple - "rand(10.minutes.to_i)". But still, I don't understand it.

Heh...I also ran into an issue with ActiveSupport::Duration, though in my case when passed as the only argument to a method with a signature along the lines of `f(time = 30, [star][star]options)`, with the error involving #to_hash. Since newer versions of ActiveSupport fix it, I didn't look into it too careful (just called #to_i). I'm glad you did!

Yeah sounds like in the same ballpark. David Stostik did a nice writeup of the oddities of ActiveSupport::Duration 4.1 here http://www.bnjs.co/2015/01/14/rails-date-class-durations-and....

I'm surprised that I haven't seen anything about that respond_to? change in the blogs; maybe I've just missed it. I might blog this, although I hate ending a post with "gosh I don't know about this one". Makes me feel like I haven't done all my homework.

Ah ha! It was a Ruby bug... longer writeup here:

http://thomasleecopeland.com/2016/06/26/basicobject-is-a-ran...

Reply on news.ycombinator.com