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 the API before comes and sees code that uses it, they can understand the code. But that only works if APIs do constrain themselves to the design patterns - constraint is key to the advantageous application of design patterns to APIs. java.util.stream does not sit by itself, it is one of hundreds of APIs on the JVM alone, including other languages it's among thousands of APIs that offer a functional API with filter and count abstractions. All of these APIs share filter/count as well established, well understood, instantly readable and understandable concepts. You don't have to know anything about java.util.stream to be able to understand exactly what filter(predicate).count() is doing. And this bootstrapping off this large ecosystem of APIs is one of the things that make java.util.stream a good API. But if it were to add count/findFirst variants that add predicates? It's not unprecedented, but it is by far less common, which makes it less understandable. That doesn't mean we never add convenience methods, but they do have to add a high degree of convenience to diverge from the well established patterns, and in this case, the convenience added is only small.
On Fri, 9 Nov 2018 at 04:39, Roger Riggs <roger.ri...@oracle.com> wrote: > 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 ends up impinging on every > developers learning curve. > > $.02, Roger > > > On 11/07/2018 08:00 PM, Jacob Glickman wrote: > > 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 Stream? > > If this is supported, I'd gladly create the webrev & tests for it! > > > > I suppose the method signature can be something along the lines of: > > > > long count(Predicate<? super T> predicate) > > > > It would also seem reasonable to give this method to IntStream, > > DoubleStream, and LongStream, but allowing them to use IntPredicate, > > DoublePredicate, and LongPredicate respectively. > > > > Thanks, > > > > Jacob Glickman > > -- James Roper Architect, Office of the CTO, Lightbend, Inc. @jroper <https://twitter.com/jroper> <https://www.lightbend.com/>
