Closed GoogleCodeExporter closed 9 years ago
Lists and *Iterables
Original comment by abry...@gmail.com
on 17 Jul 2009 at 8:06
A number of other places in the API don't follow the producer-extends, consumer-
super pattern. I found:
- Functions.forMap (both of them) could accept Map<? super K, ? extends V>
- Functions.compose could accept Function<? super B, ? extends C>, Function<?
super A, ? extends B> f
- Functions.predicate could accept Predicate<? super T>
- Predicates.compose
- Suppliers.compose
- Collections2.filter (the collection parameter can be ? extends E)
- Maps.transformValues
- and more
A number of these probably wouldn't ever cause issues if they weren't changed,
but I
thought I'd point them out to see what other people's opinions on them are.
Original comment by abry...@gmail.com
on 17 Jul 2009 at 10:32
This is a FAQ, and I sincerely regret that our posted FAQ is awful (it's
basically
still just the frequently *anticipated* questions that I wrote before the
library
gained any popularity!).
In all the cases you cite, the signatures we have are sufficient to pass any
possible
valid input you like to the library. For example, Collections2.filter() will
accept
any Collection. A wildcard is not necessary. This seems to conflict with
"PECS"
which you cite, but the thing to realize in these methods is that these types in
question are *neither producers nor consumers*; they are what I call
"pass-through"
types.
Now if you can construct a bit of client code that attempts to invoke one of our
libraries but can't because of missing wildcards, that's another story!
Original comment by kevin...@gmail.com
on 22 Jul 2009 at 10:08
Original issue reported on code.google.com by
abry...@gmail.com
on 17 Jul 2009 at 7:53