The comment above the method specifically states the supplied param must respond to include?, but allows a method that doesn't fall through to a NoMethodError. Instead it should raise a more descriptive error.
added an exception to Object#in? to match the methods documentation
Can you benchmark this version against the vanilla one? Curious how much slower it is to have a respond and a rescue up front than not. On Ruby 1.9, the version without is only 23% slower than straight include?
I don't know if we really need to explicitly check for the error or not. I do understand that it will surely get NoMethodError for #include?, but don't know if having an error at #in? level would be neccessary.
Anyway, my suggestion for this would be cache the NoMethodError returned from #include? and change the exception message. I think in that case we won't suffer from upfront rescue.
Actually, we can just catch NoMethodError and reraise an ArgumentError instead. That's the way to go. Then there's no preemptive check and thus no cost. Please make it so (and include tests as well as documentation, so people know which exception to expect.)
I don't think we need to change this. NoMethodError is descriptive enough.
@josevalim just recently removed several instances of the type of rescue/raise combo you are suggesting: df5691a
-1. This is usually referred as chicken typing. There is no need check if it responds to something, runtime will tell us.
Yes, -1 on the first implementation, but having an ArgumentError makes more sense than a NoMethodError because what's failing is that the first argument doesn't live up to what you expect. Ultimately it doesn't matter much, but it would be nicer.
Only rescue a thrown NoMethodError, don't preemptively check for #inc…
…lude?; added tests
Okay, I added the test and changed it to catch a NoMethodError.
@jfirebaugh But if you call 1.in?(1), a NoMethodError isn't the problem. The problem is that you actually passed in a bad argument, and so the proper ArgumentError should be raised. If you get a NoMethodError, you need to know the internal implementation of #in? to understand what happened.