Hi Mandy, My recommendation is to go with with PECS whenever possible, even if some aspects are redundant.
Paul. > On 5 Nov 2015, at 22:48, Mandy Chung <[email protected]> wrote: > > >> On Nov 4, 2015, at 5:00 AM, Remi Forax <[email protected]> wrote: >> >>> >>> Good point. Damn, i don’t like wildcards :-) >>> >>> The following works fine: >>> >>> static <T> Function<Stream<T>, Long> counter() { >>> return Stream::count; >>> } >>> >>> But there could also cases where one is stuck using a wildcard: >>> >>> Function<Stream<?>, Long> f = Stream::count; >> >> >> Wildcards are not that complex, but because they are use-side annotations, >> it's really easy to forget them, and IDEs do not help here :( >> >> I really hope that the JEP about declaration site variance [1] will be >> implemented at the beginning of jdk 10, it will remove the need of wildcards >> for functional interfaces. >> > > Remi, Paul, > > The current StackWalker::walk method: > <T> T walk(Function<Stream<StackFrame>, T> function) > > This would mean that the StackWalker API is intended to work with a function > taking Stream<StackFrame> but not Stream<?>. > > Changing to > <T> T walk(Function<? super Stream<StackFrame>, ? extends T> function) > > will allow use of some existing functions taking Stream<?>. I don’t object > changing it to use wildcard. > > However, the StackWalker API is specific for reading StackFrame and I would > expect it’s reasonable if it doesn’t work with a function taking Stream<?> as > the useful functions such as Stream::count, > Stream::collect(Collectors.toList(…)) can be used. > > Just want to double confirm the advice which way to go. > > Mandy
