On 10/7/16 12:40 PM, Stefan Zobel wrote:
What's wrong with the alternative "additional bounded type parameter" approach?
Couldn't we also get by with something like
<V, U extends V> Optional<V> flatMap(Function<? super T, Optional<U>> mapper)
and
<S extends T> Optional<T> or(Supplier<Optional<S>> supplier)
Personally, I find that much easier to digest. But that's only me, of course.
Yes, the additional type parameter seems to work for this example. I'm a bit
surprised.
I think it's mostly a style thing. To me, a type parameter carries a certain
amount of semantic weight, implying that it's a concern that the caller needs to
pay attention to. (Note that type parameters are documented using the javadoc
@param tag, and by convention every parameter must be documented.) By contrast,
a wildcard says "anything that satisfies the constraints" but we don't care
exactly what it is.
If a type parameter is used only once, it can (always, I think) be replaced by a
wildcard. After having looked at lots of generic APIs, it seems to me that a
style has emerged where wildcards are used whenever possible, and type
parameters are used only when necessary, e.g. when the exact same type is
required in multiple places. I don't know if this is actually written down
anywhere though.
A difference *would* arise between the multiple-wildcards and
additional-type-parameter approaches, if it were possible to have subclasses of
Optional.
Of course, it doesn't apply to this case, since Optional is final, and we have
no plans to make it non-final!
s'marks
