Additional method on Stream

[Paul Sandoz]

On Apr 28, 2015, at 11:18 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
> On 27 April 2015 at 16:23, Paul Sandoz <paul.sandoz at 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