This may be a rare need, but I thought I had a case where I wanted a matcher to pass or fail for both the "should" and "should not" cases. The matcher was comparing the ordering of two potential events, but if one doesn't occur, the comparison is invalid, so it was unclear what the matcher result should be, but it seemed like the matcher should either always pass or always fail, regardless of the should/should-not context.
In the end, I decided to make the positive case fail when the reference point was missing, as the point was debatable and in the negative (should not) case it was clear that the matcher should pass. I will monitor the situation and see if this is the right decision.
In any case, I believe there could be a use for having the +evaluate+ method have access to the should/not context, just like the failure message code has. I propose adding an +@optional+ method to the +KWMatching+ interface, +evaluateForShouldNot+, which is called if present in the negative matcher case. This should be a very easy addition, and the only argument against doing it now is that it might not really be needed. But if the time comes, I have a plan!
This may be a rare need, but I thought I had a case where I wanted a matcher to pass or fail for both the "should" and "should not" cases. The matcher was comparing the ordering of two potential events, but if one doesn't occur, the comparison is invalid, so it was unclear what the matcher result should be, but it seemed like the matcher should either always pass or always fail, regardless of the should/should-not context.
In the end, I decided to make the positive case fail when the reference point was missing, as the point was debatable and in the negative (should not) case it was clear that the matcher should pass. I will monitor the situation and see if this is the right decision.
In any case, I believe there could be a use for having the +evaluate+ method have access to the should/not context, just like the failure message code has. I propose adding an +@optional+ method to the +KWMatching+ interface, +evaluateForShouldNot+, which is called if present in the negative matcher case. This should be a very easy addition, and the only argument against doing it now is that it might not really be needed. But if the time comes, I have a plan!