Re: generics:< ? >vs.< T >
On 03/09/2011 07:50 PM, Joshua Cranmer wrote:
On 03/09/2011 09:11 AM, Robert Klemme wrote:
Btw, has anybody an explanation why I can do copy1() from above but not
public static<V1, V2 super V1> void copy0(final Map<?, V1> source,
final Map<? super String, V2> target) {
// work
}
? This errors out with a syntax error at "super" between "V2" and "V1".
Wildcard types involving super, IIRC, were primarily intended to handle
edge cases in collections, e.g.:
public static <T> T max(Collection<T> coll, Comparator<? super T> comp);
The idea being that most of the time, you want the lower bounds on types
(e.g., this type is some sort of Number) as opposed to the upper bound,
which maps roughly to "I need a type which can accept a String being
passed in". Therefore, it is less useful than extends bounds in terms of
parameterized types. So I think it falls under the category of trying to
prevent you from using the super construct willy-nilly.
I'm not sure about that "most of the time". Typically the usage of a
type in a method's signature determines what kind of bound one needs:
public <A extends InputType, R super OutputType> void doWhatever(A x,
List<R> out)
A needs to be at least InputType so I can be sure I have access to all
InputType methods in the method. R needs to be a super class of
OutputType in order to be able to pass an OutputType instance.
Note, we do not need the bound for the return type:
public <A extends InputType, R super OutputType> R doWhatever(A x)
with
public <A extends InputType> OutputType doWhatever(A x)
In terms of class types, a super bound really doesn't make sense ("this
collection can only store objects that are a supertype of String"?); in
the case of method parameterized types, you can generally rewrite the
wildcard in terms of extends, so its utility is significantly less there.
Although I say that, I'm not fully persuaded of that design approach...
:-) Thanks for your insights nevertheless.
Kind regards
robert