Skip to content

Conversation

ydah
Copy link
Member

@ydah ydah commented Oct 6, 2025

Fixes: #2012

Another solution of #2121


Before submitting the PR make sure the following are checked:

  • Feature branch is up-to-date with master (if not - rebase it).
  • Squashed related commits together.
  • Added tests.
  • Updated documentation.
  • Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
  • The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

If you have created a new cop:

  • Added the new cop to config/default.yml.
  • The cop is configured as Enabled: pending in config/default.yml.
  • The cop is configured as Enabled: true in .rubocop.yml.
  • The cop documents examples of good and bad code.
  • The tests assert both that bad code is reported and that good code is not reported.
  • Set VersionAdded: "<<next>>" in default/config.yml.

If you have modified an existing cop's configuration options:

  • Set VersionChanged: "<<next>>" in config/default.yml.

@ydah ydah requested a review from a team as a code owner October 6, 2025 11:31
@pirj
Copy link
Member

pirj commented Oct 6, 2025

My uncertainty is more in the area if we need to fix this at all.
match sounds generic, but Ruby has clearly defined conventions for object equality, which is preferable to a generic and vague match.

I tend to agree that RSpec’s match matcher is overreaching, but it is how it is.

Even though the be_match is not the same as match, but I fail to imagine a situation where two objects are == or ===, but do not match.

@ydah
Copy link
Member Author

ydah commented Oct 6, 2025

If there's another case where this solution might be useful, it would be if there've redefined match themself, right? In that case, this might be usable. What do you think?

@pirj
Copy link
Member

pirj commented Oct 6, 2025

I’m not sure I understand, can you give an example?

Forgot to mention that be_match sounds weird, just as any be_verb would. On the contrary, be_adjective (be_empty), sounds right when you read it. Long story short, I would rather use expect(subject.match?(reference)).to be_true to the other style even if it’s more verbose. Or is_expected.to match(reference) even if this feels like an abuse of the match matcher.

@ydah
Copy link
Member Author

ydah commented Oct 6, 2025

Oops, what I was talking about was exactly the case in the Issue #2012. This cop offense follows standard usage, and we don't need to proceed with this right now. I'll close this for now.

@ydah ydah closed this Oct 6, 2025
@ydah ydah deleted the 2012-2 branch October 7, 2025 06:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RedundantPredicateMatcher is not a safe autocorrect

2 participants