There are four kinds of matchers which are referred to within the RSpec source code:
(Built-in) matchers: Also simply shortened to "matcher", these are instances of RSpec::Matchers::BuiltIn::Base and are created via convenience methods which are available in all RSpec example groups (e.g. eq for RSpec::Matchers::BuiltIn::Eq, include for RSpec::Matchers::BuiltIn::Include, etc.).
Custom matchers: These are matchers that end users can create via RSpec::Matchers.define. They are not instances of RSpec::Matchers::BuiltIn::Base, but rather RSpec::Matchers::DSL::Matcher.
Aliased matchers: These are matchers which act just like other matchers but are created via a different method name and hence have a different description to match. For instance, include has four aliases: a_collection_including, a_string_including, a_hash_including, and including. The objects that such methods return are actually an instance of RSpec::Matchers::AliasedMatcher and wrap the original matcher object.
Describable matchers: These are matchers which satisfy a minimal matcher interface including description, so they effectively match both built-in and custom matchers. More formally, they are objects which pass the check that RSpec::Matchers.is_a_describable_matcher? makes: that is, they are either instances of RSpec::Matchers::BuiltIn::Base, or they respond to matches? and description and either failure_message or failure_message_when_negated.
So far in the SuperDiff code we have been using the phrase "fuzzy object" to describe an aliased matcher. That was derived from rspec-support's FuzzyMatcher class, which compares two objects with the consideration that either could be an RSpec matcher object. But that's not an official term, and so it could be confusing if we use that.
This commit corrects this term to simply "RSpec matcher object", except in the case where it was being used to test whether a value was an aliased matcher, in which case that term is now used.
There are four kinds of matchers which are referred to within the RSpec source code:
eqfor RSpec::Matchers::BuiltIn::Eq,includefor RSpec::Matchers::BuiltIn::Include, etc.).RSpec::Matchers.define. They are not instances of RSpec::Matchers::BuiltIn::Base, but rather RSpec::Matchers::DSL::Matcher.includehas four aliases:a_collection_including,a_string_including,a_hash_including, andincluding. The objects that such methods return are actually an instance of RSpec::Matchers::AliasedMatcher and wrap the original matcher object.description, so they effectively match both built-in and custom matchers. More formally, they are objects which pass the check thatRSpec::Matchers.is_a_describable_matcher?makes: that is, they are either instances of RSpec::Matchers::BuiltIn::Base, or they respond tomatches?anddescriptionand eitherfailure_messageorfailure_message_when_negated.So far in the SuperDiff code we have been using the phrase "fuzzy object" to describe an aliased matcher. That was derived from
rspec-support's FuzzyMatcher class, which compares two objects with the consideration that either could be an RSpec matcher object. But that's not an official term, and so it could be confusing if we use that.This commit corrects this term to simply "RSpec matcher object", except in the case where it was being used to test whether a value was an aliased matcher, in which case that term is now used.