GoogleCodeExporter
commented
8 years ago Since posting this issue I've tested against the head revision. Some of the
problems
are fixed. In particular, changing signatures from
<K,V> Matcher<Map<K,V>> hasKey(K key)
to
<K> Matcher<Map<K,?>> hasKey(K key)
removing the unbound V parameter allows the compiler to infer the map value
type from
the first parameter in the assertThat statement. This allows hasKey to work in a
typed map. (The same holds for hasValue, though I'll stick to hasKey in this
post for
clarity.)
Unfortunately, the more I look at this problem, the more it seems that to solve
the
more general problem we need a wider solution than just in the method signatures
relating to map matchers. I hoped that just by widening the bounds on the
parameter
type of the matcher would allow this all to fall out, but I believe we need
something
more, closer to what I suggested in the message I posted to the group, link
above.
The next part of the problem comes when, for a map with parameters K, V, we try
to
match a key with type J <: K. One contrived example: J = Integer, K = Number.
Map<Number, V> map = getMap();
assertThat(map, hasKey((Number) Integer.valueOf(1))); // compiles against trunk
assertThat(map, hasKey(Integer.valueOf(1))); // fails to compile
Clearly more realistic use cases will come up, for example consider
parametrising the
key as an interface.
It turns out that there is a simple solution to all of this. The reason it's
difficult and requires a lot of generic magic to get the above statements to be
valid
is because we have this single-sided restriction on the type parameter of the
Matcher, that the actual value being matched is of a type bounded above by the
parameter type of the Matcher. There is no a priori reason that this should be
so, as
opposed to the converse.
In my post to the mailing list previously I asked for ideas about how to get
around
some of these generic issues, and my suggestion at the time was to remove the
parameter from the Matcher interface. I understand now that this isn't possible
due
to JMock integrations.
It seems to me that the other suggestion I gave (and disregarded) might be an
approach to consider. In the signature for assertThat, rather than associate
the type
of the "actual" value and the parameter type of the matcher (either by
identifying
them or stipulating that one bounds the other above/below) we should
disassociate
them entirely. We can still have the parameter on the Matcher interface and it
can
still have the same interpretation as currently, but we're also able to make
more
assertions that are reasonable to make, for example
assertThat(3, greaterThan(2.0))
assertThat(3.0, greaterThan(2))
Note that with this change to assertThat we can even do away with all of the
extra
generic magic.
So my proposal is to rewrite the assertThat methods with the following
signatures
(requiring no other code changes):
<T, M> void assertThat(T actual, Matcher<M> matcher)
<T, M> void assertThat(String reason, T actual, Matcher<M> matcher)
All of the tests pass, again with no other code changes.
For extra context I've attached some discussion of the generic magic I tried to
go
through to get this to work without changing assertThat - I'm almost certain it
won't
work, due in part because Java's type inference is not strong enough. I've also
attached some test cases. They don't compile against current trunk (r318), but
compile and pass with these changes.
Original comment by joe.kear...@gtempaccount.com on 15 Oct 2008 at 8:58
Attachments:
- TypeInferenceTest.java
- [more generics in the map matchers.txt](https://storage.googleapis.com/google-code-attachments/hamcrest/issue-47/comment-1/more generics in the map matchers.txt)
Original issue reported on code.google.com by
joe.kear...@gtempaccount.comon 9 Sep 2008 at 10:09