JavaHamcrest icon indicating copy to clipboard operation
JavaHamcrest copied to clipboard

Expose paramater type info where available to help with Java 7 issues.

Open louisth opened this issue 12 years ago • 4 comments

Lots of matchers know what type of object they are dealing with, but there's currently no way to get at that information. This type information would be really helpful for some Hamcrest clients, such as JMock, in dealing with the new typing issues introduced in Java 7. (Specifically, with this fix JMock clients won't have to change their tests when JMock is made Java 7 compilable.) I propose adding a getParameterType method to Matcher that lets the matchers that know their type expose that information (and other Matchers can just return null). BaseMatcher provides the default implementation so clients do not have to make any code changes.

I'm bundling two other small fixes. AnyOf and AllOf now have the same base class, and the mismatch description for TypeSafeDiagnosingMatcher now matches TypeSafeMatcher. If this is a problem, I'd be happy to resubmit these separately.

louisth avatar Jan 18 '13 18:01 louisth

We probably need to do this at some point. My preference is to pull up the implementation from TypeSafeMatcher. I think the implementation might be better if the default value is Object.class rather than null

sf105 avatar Jan 19 '13 13:01 sf105

TypeSafeMatcher looks at the raw parameter type of one of the methods. This works when the derived class provides a method with the desired type explicitely coded (e.g., StringContainsInOrder), but doesn't work in all cases. For example, IsNot needs to delegate to the matcher it wraps. Even clearer, IsEqual works for any object type and so the matches method has an Object raw parameter type, but a better guess for the effective template parameter type (which JMock needs) is to look at the type of the expectedValue. (OrderingComparison is a similar example.) If we did change the base behavior, we could always overrride to get the needed behavior in these cases of course. I guess I just don't see much difference between pulling the raw-type-sniffing code from TypeSafeMatcher up to BaseMatcher and actually making TypeSafeMatcher the standard base class (pull everything up?). I'm not even sure that there are any classes that COULD benefit from TypeSafeMatcher that do not already extend it. I was trying to be good and went with a smaller change.

Why not return Object.class by default? Because the parameter type provided by this method is truly a guess, I thought it made more sense to return null to indicate that the matcher is choosing not to hazard a guess (either because it's not implemented (BaseMatcher) or because it has no information available (IsNull)) and return Object.class when the matcher really does think its parameter type is Object. I was trying to be more accurate in case some library besides JMock needed to use this feature in the future.

louisth avatar Jan 31 '13 14:01 louisth

@louisth fancy rebasing this from master, as hamcrest-core and hamcrest-library have been refactored a lot and also deprecated, so that everything is just in hamcrest.

nhojpatrick avatar Jun 28 '20 22:06 nhojpatrick

Going to try and kick start hamcrest, so if you want to get it merged, please rebase from the branch v2.3-candidates. Still trying to understand how has permissions to perform a release.

nhojpatrick avatar Feb 13 '22 12:02 nhojpatrick