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. 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. 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
