Hi --
I'm not sure I see the point, since it's just a wrapper to include? I don't agree with the point about its being grammatically more correct. (I know include? isn't includes? but that's something Matz has decided to do [respond_to? is another example], and isn't grounds for not using a method.)
I think semantically and object-wise, the idea of a collection having knowledge of whether it includes something makes more sense than an arbitrary object having knowledge of whether it's in a collection. And since this doesn't add anything (just masks include?), I'm not sure there's a strong case for it.
David Black
I think it mirrors this way of iterating:
for object in collection
do_something
end
do_something if object.in? collection
Those are two completely different things. This RCR doesn't have anything to do with iterating. It's two completely different uses of the word "in".
I completely understand they are different things, but you have to be able to appreciate the similarity.
I'm afraid I don't see in any of this an argument for changing or adding to the language.
I'd prefer this instead:
https://rcrchive.net/rcr/show/241
I think that:
if item in collection
makes much less sense than:
if item.in? collection
in the Ruby way.
Don't think of it as "the object knows whether it's in a collection". If it was called Object#equal_to_any_of? would you have the same problem? Objects know how to compare themselves to other objects, so it's a relatively simple extension to compare to an Enumerable.
I don't agree that in? is more grammatically correct. The reason include? makes some people uncomfortable in specific situations is that it puts the wrong object closer to the 'if'. In that sense, the arguments in favor of in? ought to be similar to those in favor of the statement modifier form of if.
This ruins the balance of Ruby to make it into English.
obj.method(other) generally returns information about the state of obj, not other. It makes it much easier to figure out what a method does when you can almost always make that assumption. I use Ruby because it reduces my thinking load; this proposal increases it.
This introduces the opportunity to err and definitely slows our application when we repeat, in Ruby code, what the Ruby interpreter already does for us: throw an error if #include? isn't in the supposed enumerable.
It doesn't seem much different from String#match knowing to delegate to Regexp#match. These things are in the core for a reason.
I'm not sure I see the point, since it's just a wrapper to include? I don't agree with the point about its being grammatically more correct. (I know include? isn't includes? but that's something Matz has decided to do [respond_to? is another example], and isn't grounds for not using a method.)
I think semantically and object-wise, the idea of a collection having knowledge of whether it includes something makes more sense than an arbitrary object having knowledge of whether it's in a collection. And since this doesn't add anything (just masks include?), I'm not sure there's a strong case for it.
David Black
I think it mirrors this way of iterating:
for object in collection
enddo_something if object.in? collection
Those are two completely different things. This RCR doesn't have anything to do with iterating. It's two completely different uses of the word "in".
I completely understand they are different things, but you have to be able to appreciate the similarity.
I'm afraid I don't see in any of this an argument for changing or adding to the language.
I'd prefer this instead:
https://rcrchive.net/rcr/show/241
I think that:
makes much less sense than:
in the Ruby way.
Don't think of it as "the object knows whether it's in a collection". If it was called Object#equal_to_any_of? would you have the same problem? Objects know how to compare themselves to other objects, so it's a relatively simple extension to compare to an Enumerable.
I don't agree that in? is more grammatically correct. The reason include? makes some people uncomfortable in specific situations is that it puts the wrong object closer to the 'if'. In that sense, the arguments in favor of in? ought to be similar to those in favor of the statement modifier form of if.
This ruins the balance of Ruby to make it into English.
obj.method(other) generally returns information about the state of obj, not other. It makes it much easier to figure out what a method does when you can almost always make that assumption. I use Ruby because it reduces my thinking load; this proposal increases it.
This introduces the opportunity to err and definitely slows our application when we repeat, in Ruby code, what the Ruby interpreter already does for us: throw an error if #include? isn't in the supposed enumerable.
It doesn't seem much different from String#match knowing to delegate to Regexp#match. These things are in the core for a reason.