-
-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the ability to add a "chain" to an existing matcher #1219
Comments
We don't really encourage people to monkey patch or inherit from our matchers, they are not even encouraged to know the class names (by which I mean they are tagged as So if we were going to do this, I'd really want to lookup other matchers by name, and not by the class; and I'd want the DSL to take the class and create a new one from it, apply the block and override the old implementation. So it would look more like:
But even this still risks breaking implementations that also rely on names... |
Thanks Jon for your answer. After everything you say, it seems to be a bad idea :) Feel free to close this feature request if you think we should not accept a proposal for this.😉 |
If you want to investigate this further I don't mind, if you want to close I don't mind, I just wanted to point out the potential pitfalls :) |
Ok. I will let the feature request as open. If no one request it, I will close it before RSpec 4. :) |
Please correct me if I'm mistaken, but I'm under the impression this can be done with something like:
|
The first is no better/worse than @benoittgt's ideas, the second overrides our implementation and would have the same problems with other uses, but at least it would be deliberate by the user. |
Does it? |
It does if we define |
It can probably overlap with our Also, this doesn't have to be defined in |
This is my point, it doesn't prevent affecting an existing matcher when it overrides how that matcher is used. Remember people use the matcher names to access matchers, not the classes... |
I'm sure I quite understand why you are so opposed to this technique? Doesn't RSpec::Matchers.define_chain BuiltIn::HaveAttributes do
chain :with_value do |actual_hash|
expected.value == actual_hash.value
end
end affect an existing matcher in the same way? The reason I'm proposing it is that there's (probably) nothing needs to be done, and there's nothing to maintain except for adding documentation for how to do this. As opposed to |
I'm not opposed to it, I'm just saying it has similar drawbacks to the other suggested implementations, so yes does affect existing matchers in the same way.
Remember that classes are not a public API for our matchers, your proposed solution would still require us to make changes to our support, I'm not convinced we need to allow this personally I'm just open to @benoittgt researching it more :) |
Subject of the issue
This is a feature request. I think it could be a good idea to let people "extend" RSpec matchers with chaining capabilities.
For exammple:
The text was updated successfully, but these errors were encountered: