RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

[Stuart Marks]

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