Hello!
I see myself having to often call count() as a terminal operation on a
Stream immediately after performing a filter operation. How feasible would
it be to add an overloaded count() method that accepts a Predicate, which
it uses as a filter before returning the count of elements in the Stre
Hello!
I see myself having to often call count() as a terminal operation on a
Stream immediately after performing a filter operation. How feasible would
it be to add an overloaded count() method that accepts a Predicate, which
it uses as a filter before returning the count of elements in the Strea
findFirst(Predicate predicate) would be nice too
чт, 8 нояб. 2018 г. в 8:01, Jacob Glickman :
> Hello!
>
> I see myself having to often call count() as a terminal operation on a
> Stream immediately after performing a filter operation. How feasible would
> it be to add an overloaded count() meth
What's wrong with `filter(predicate).count()`? Saving nine characters?
With best regards,
Tagir Valeev.
On Thu, Nov 8, 2018 at 8:02 AM Jacob Glickman wrote:
>
> Hello!
>
> I see myself having to often call count() as a terminal operation on a
> Stream immediately after performing a filter operat
Tagir,
Nothing is wrong with it, but I think the addition of the convenience
method(s) would help to improve readability in some cases. Personally, I'd
much rather have the option of writing `.count("Java::equals")` than
`.filter("Java"::equals).count()`. As Zheka stated, this type of
convenience
There was a typo in my last e-mail:
`.count("Java::equals")` should be `.count("Java"::equals)`
Thanks,
Jacob Glickman
On Thu, Nov 8, 2018 at 9:02 AM Jacob Glickman wrote:
> Tagir,
>
> Nothing is wrong with it, but I think the addition of the convenience
> method(s) would help to improve read
Hi Jacob,
Its hard to resist the urge to add convenience methods, they look nice
and help a few developers.
However, they accumulate rapidly and end up obscuring the core
functionality.
They can hurt comprehension since they fold different functions together
and the collective API surface area
Another reason to prefer a smaller API is that it can aid the ability to
comprehend, since there's less concepts to understand. The idea behind
design patterns is that APIs constrain themselves to just using the well
established and understood patterns, which means when someone who has never
seen t
It is entirely feasible. But, that’s not the criteria for adding it.
There are frequent calls for fusing methods that are commonly used together,
such as filter+map. Our position has been that the stream API is better served
by providing mostly orthogonal primitives, and letting developers c
Exactly right.
Note, though, that count() is _already_ a convenience method! You could call
.collect(counting()) instead. So, why were we willing to add count() and
similar methods, when we’re not willing to add this one? Several reasons:
- Discoverability. Collect() is complicated, and un
10 matches
Mail list logo
