RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()
stuart.marks at oracle.com
Fri Oct 7 21:38:57 UTC 2016
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)
> <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
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
A difference *would* arise between the multiple-wildcards and
additional-type-parameter approaches, if it were possible to have subclasses of
Of course, it doesn't apply to this case, since Optional is final, and we have
no plans to make it non-final!
More information about the core-libs-dev