himanshudixit / google-collections

Automatically exported from code.google.com/p/google-collections
Apache License 2.0
0 stars 0 forks source link

Collections2.transform parameters should match Lists/Iterables.transform parameters #206

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Collections2.transform's function parameter should have a generic type of 
Function<? super F, ? extends T> instead of <? super F, T> to match the 
transform method in Lists and Collections.

Original issue reported on code.google.com by abry...@gmail.com on 17 Jul 2009 at 7:53

GoogleCodeExporter commented 9 years ago
Lists and *Iterables

Original comment by abry...@gmail.com on 17 Jul 2009 at 8:06

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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