Adds not_in? onto Object

[jmccartie]

Introduce not_in? on Object.

As an opposite method for in?, not_in? provides equivalent support for exclusion. This turns this:

    [1,2].exclude?(user_id)

...into this:

    user_id.not_in?([1,2])

[rails-bot]

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.

Please see the contribution instructions for more information.

[rafaelfranca]

Thank you for the pull request but we avoid to add new core extensions in Active Support unless they are going to be used in the framework or in a large number of applications.

In this specific case, both exclude and !in? can be used.

[jmccartie]

@rafaelfranca in? is a convenience method. 100%. The purpose of this is to reduce the cognitive load with !include? (which is what in? already does for include?)

We have include? (Ruby core) and exclude? (Rails). And we have in? (Rails), but no not_in?. Why not have an opposite method to complete the pairs? This was odd to me and probably presents confusion for other Rails devs.

Why not make lives a little better for Rails devs with this simple patch?

[rafaelfranca]

Because in my opinion the core_ext of Active Support is already huge and I'd love to have things in Ruby itself not Rails.

I'm fine with adding this to Rails, but it should be proposed to ruby too. If you believe it is that useful, it should be in the language.

[jmccartie]

@rafaelfranca Is that what you're planning to do with in? and exclude?

[jmccartie]

@rafaelfranca

I'm fine with adding this to Rails, but it should be proposed to ruby too. If you believe it is that useful, it should be in the language.

Seems like a reasonable compromise. I agree it should be in core. I can tackle that later and then reverse this?

[rafaelfranca]

We are taking that direction, yes. Object#itself was implemented first in Rails and later added to Ruby. Enumerable#sum was implemented in Rails and later added to Ruby. We are proposing String#blank? to Ruby too.

We never proposed in? and exclude? but that could be proposed along with not_in?. I guess I'm going to merge this and propose those later, unless you want to do.

[rafaelfranca]

✂️ this blank line.

[jmccartie]

@rafaelfranca

I guess I'm going to merge this and propose those later, unless you want to do.

I don't mind doing it, but you probably have more experience proposing to Ruby core than I do. Happy to help if you need me.

[jmccartie]

@rafaelfranca Not sure what's up with those Travis failures. They look systemic. Any ideas?

[rafaelfranca]

Yeah, it were broken on master, but already fixed.

[rafaelfranca]

Thank you for the pull request!

[jmccartie]

@rafaelfranca Thanks for merging and for re-considering!

[matthewd]

"exclude?" is a nicer phrasing, for some uses, vs "not include?"; "not_in?" does not have the same merit over "not in?".

[jmccartie]

@matthewd I don't follow. "not in" in the verbal (and logical opposite of) "in". Are you suggesting another phrase instead?

[matthewd]

@jmccartie my point is that ruby already has a perfectly satisfactory way of writing "not". The natural language opposite of "include" is "exclude", whereas, as you say, the natural language opposite of "in" is "not in" -- we don't need a new method for that, because that's exactly how !in? reads.

I don't see any argument for this that wouldn't equally apply to a similar opposing method for every other ? method.

[jmccartie]

@matthewd Yup, I completely get your point. And I certainly wouldn't propose we create opposites for every ? method.

However, the original purpose of in? is to place the subject first in the query. For example, it's the English equivalent of changing "Home, are you in it?" to "Are you at home?". It's not a need, but it certainly helps with cognitive load when reading and writing code. I would liken it to unless -- another great way to reduce the overhead of if !something. Do we already have something for negation? Yes. Can we make a simple change to make developer's lives a little nicer, you bet.

And I agree with Rafael -- I'd love to see these methods (including Rails' in? and exclude?) added to Ruby core to go along with other language helpers that make Ruby a delight to write.

Cheers,
Jon

[matthewd]

Do we already have something for negation? Yes. Can we make a simple change to make developer's lives a little nicer, you bet.

I still haven't seen an argument that doesn't work just as well for is_not_a? / !is_a? or not_nil? / !nil?. in? exists to avoid a (sometimes) awkward subject/object inversion, which requires far more mental gymnastics than a floating 'not'... and if the latter is worthy of sugar, there's no reason we should stop at in?.

Perhaps you'd be better served by suggesting a syntax extension upstream, such that foo.!bar == !foo.bar. It's certainly true that "not foo is bar" is rarely the natural choice over "foo is not bar" -- but as long as that is the form allowed by the language syntax, and we have not chosen to globally "correct" it, a single method in that direction is going to create far more confusion than it prevents.

[dhh]

I'd love to have a method for this, but not_in? doesn't clear my bar as nicer than !x.in?. We've tried several times in the past to come up with a great method name for this, but we've failed every time. not_in? was considered at every occasion.

You can read the long history of rejecting not_in? in #258, #12912, and #265.

[jmccartie]

@dhh Very sad to see this get discussed, merged, then thrown away because of "history".

not_in? may not be linguistically 100% there, but it fills a need and I've gotten a lot of good feedback on it. Not sure the benefit of throwing this out completely. It's a very minor addition and doesn't change existing behavior. As mentioned earlier, it's easier to grok than !in? and completes the pairing between present?/blank?, include?/exclude? and in?/<nothing>.

For the record, this comment explains it perfectly. not_in? is self-documenting and works just fine in the English language.

[dhh]

This isn't because of "history" but because of all the reasons examined in those prior PRs. From my perspective, there's no new information or arguments that we didn't already consider at length in 2011 and 2013, as per the referenced tickets.

Thankfully, Ruby and Rails make it oh-so-easy to include a method like not_in? on your own project. You don't need neither Matz' or my blessing to do so. If you like not_in?, then you can add it to your own dialect. That's all ActiveSupport is anyway. A dialect of Ruby intended for Rails development.

So please do have at it in your own project, and do return with a new PR if you get an epiphany on naming that was not previously considered. I like the functionality, but until there is a great name for it, I'd rather live without. (This principle of waiting for the right name, and rejecting features until we find them, has a long tradition in Ruby core development as well. One that I'd happy to continue).

[jmccartie]

@dhh I humbly disagree. And I wish this could get discussed again.

But... I very much appreciate you taking the time to provide a lengthy response. Cheers. 🍻

[nickpoorman]

I believe the term you're looking for is "exclusive".

[jmccartie]

@nickpoorman For this behavior? No, I disagree. "not in" is typically used in English here. For example:

• "His heart is not in it"
• "The item is not in the list"
• "This number is not in this array"
• "This module is not in this class"

"exclusive" and "ex?" (as suggested in the other PR's) does not fit here, in my opinion.

[crazymykl]

Object#out?

[maxp-edcast]

I don't want to open a new issue about it but I do want to give my 2 cents on it, even though it's a super old thread (sorry ..)

I have this code I want to refactor:

if params[:status].present? && User::PERMITTED_STATUSES.exclude?(params[:status])

I want to make it:

if params[:status]&.not_in? User::PERMITTED_STATUSES

In this example, since the safe navigation operator is used, !in? cannot simply be used instead of not_in?. So I would implore @dhh to reconsider this, yet again.

Granted, I could simply add it to our codebase, but I like to avoid too many core patches.

[dhh]

@maxp-edcast We've gone over this a lot of times over the years. I respect this is something people are eager to have, but I haven't changed my opinion given that there's no new information available. You can write your example like:

if !params[:status]&.in?(User::PERMITTED_STATUSES)

Or

unless params[:status]&.in?(User::PERMITTED_STATUSES)

[maxp-edcast]

@dhh thanks for reading and responding. The examples you give are not the same as mine (if params[:status]&.not_in? User::PERMITTED_STATUSES) in the case that params[:status] is nil. With imaginary ruby syntax it would be if params[:status]&.!in(User::PERMITTED_STATUSES)

[dhh]

Ah! All the more reason to write it in a less confusing way, then. Combine the try and the not is a pretty subtle read. I think the first example you had with an explicit present check is preferable.

[amerov]

It is may will to broke codebase which contain some_object.respond_to? :not_in?

[akimd]

I personally feel that not_in? is way more readable that ! in?. In short examples such as x.not_in?(l), I agree it makes hardly any difference. But the difference is huge when you chain several calls.

!sale.sale_items.first.book.author.country.alpha_3_code.val.in?(['FRA', 'GBR'])

is far less readable than

sale.sale_items.first.book.author.country.alpha_3_code.val.not_in? ['FRA', 'GBR']

There is less mental load to remember the context of the operator. That's exactly why all the languages have x != y and not just ! x == y: it maps more easily with our way of thinking.

I regret that this has to be a method though. On this regard I prefer the (syntactic) choice of Python that features two infix operators, in and not in, mapped to Python's equivalent of include?.