Hi Lukas, Thank you for the prompt response. It's great to see toList() and so many other useful collector calls now available via Collectable.
I agree that nobody would want to create a whole new collections hierarchy, but perhaps a program could automate the process of creating extensions in some other package (e.g. xjava.util) for non-final collection classes, or wrappers otherwise, which add the Stream members (or even Seq's members!) to the Collection interface. Anyway, just a thought for a project that might be interesting and could unify collections and streams. Best wishes -Raul On Thursday, February 25, 2016 at 4:25:49 AM UTC-5, Lukas Eder wrote: > > Hi Raul, > > Thanks for your E-Mail and suggestions. I will comment inline > > 2016-02-25 4:55 GMT+01:00 Raul Santelices <[email protected] <javascript:> > >: > >> Hi, >> I was wondering if there are any plans (or any reasons against) adding >> these things to Seq or an extension of 1. Simpler stream collecting, such >> as >> items.stream().filter(...).map(...).toList() >> instead of having to use the more verbose .collect(Collectors.toList()) >> as a terminal call. >> > > Go ahead and use Seq.toList()! If you spot any other missing collector > shortcuts, do let us know and we'll happily add them if they make sense. > Note, in the latest version of jOOλ, we've added a Collectable super type, > which abstracts streams and other collections that accept Collectors: > http://www.jooq.org/products/jOO > λ/javadoc/latest/org/jooq/lambda/Collectable.html#toList-- > > >> Or even have mapToList(...) as a terminal call. >> > > To people who are used to using monads in Java/Scala, "map" / "flatMap" > always operate on the manad's content type <T>. In the case of Seq, this is > the Seq elements. So, "collect" is really the correct verb here. > > >> 2. Avoiding the need to call .stream() so that collections and streams >> are the same thing (as in Scala IIRC). For example: for List<Item> items, >> calling items.mapToList(...) would produce a transformed list. (I thought >> of using bytecode manipulation to enhance the JDK classes on class-loading >> but it would have licensing issues. Therefore, this idea would require >> creating a new class hierarchy on a separate package outside java.* which >> perhaps a program could generate) >> > > That sounds like a bad idea (the enhance the JDK classes part). Like you, > I do wish for a lot of map() and similar methods on the existing JDK > collection types as well, but the expert groups had decided against these > features. Right now, there are no plans for re-implementing a whole set of > collection types. > > Best Regards, > Lukas > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
