On Apr 28, 2015, at 11:18 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > On 27 April 2015 at 16:23, Paul Sandoz <paul.san...@oracle.com> wrote: >> One issue is there are zillions of possible more specific convenience >> operations we could add. Everyone has their own favourite. Some static >> methods were recently added to Stream and Optional in preference to such >> operations. >> >> There has to be a really good reason to add new operations. I realize this >> use-case might be more common than others but i am still yet to be convinced >> that it has sufficient weight given flatMap + lambda + static method. >> >>> BTW, I wait months before making this request to see if it really was >>> common enough a pattern, but I'm confident that it is now. >> >> Were you aware of the pattern using flatMap during those months? > > No, but if I had, I would not have used it. Its a rubbish workaround. > It creates extra objects for no value. It involves statically > importing another random utility. and it is less expressive - the > desire is to filter by type, so I want the filter method. >
It's not just a filter method it's a specific, fused filter and map method. > I do understand the desire to control methods, but API design isn't > just about minimalism, it is also about meeting common use cases in a > natural way. The parallel is of course a standard if (obj instanceof > Foo) statement in Java, where developers often curse that they have to > additionally cast obj after the check. I believe Ceylon might also do contextual type narrowing. I dunno how easy it would to modify the Java language and javac to do similar things. A separate discussion to be had... A library analogue could be: Optional<T> Class.castIf(Object obj). At the risk of increasing your wrath about flatMap, you could then do: s.flatMap(e -> Foo.castIf(e).stream()) Paul. > Why can't the compiler just do > it? (Kotlin does for example). While changing the Java language to do > this is hard, changing the Stream API would be easy, and good value > given a year's coding with streams. > > Stephen
