Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement CollectorBuilder #88

Open
amaembo opened this issue Mar 17, 2016 · 6 comments
Open

Implement CollectorBuilder #88

amaembo opened this issue Mar 17, 2016 · 6 comments

Comments

@amaembo
Copy link
Owner

amaembo commented Mar 17, 2016

There's an idea for fluent CollectorBuilder which is similar to Stream API itself. Along with OptionalCollector (see #87) it makes complex nested collectors easier to read:

Map<Integer, List<String>> res = IntStreamEx.range(22).boxed().into(
        c -> c.groupingBy(x -> x / 10, 
            c1 -> c1.flatMap(x -> StreamEx.of(x, x*2)).map(x -> "[" + x + "]").limit(5).toList()));
// group by and for each group select at most 5 elements after flatMap and map operations

Map<Boolean, List<Integer>> res3 = IntStreamEx.range(100).boxed().into(c -> c
        .partitioningBy(x -> x % 2 == 0, c1 -> c1.limit(2).toList()));
// select at most two even and two odd numbers (short-circuiting collector)

Such API would be a very complex feature, thus careful evaluation is necessary. Also current attempts show that Eclipse Luna has bad times compiling such things (Eclipse Mars.2 works fine). Probably Luna compiler should be dropped in favor of this feature.

@lukaseder
Copy link

Eclipse Luna had tons of Java 8 compiler bugs and performance issues - you should really upgrade. But sooner or later, you'll inevitably run into this show stopper here for Eclipse Mars, too:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=476718

Hmm, how does StreamEx.into(c -> c.xxx) beat StreamEx.collect(Collectors.xxx)?

@amaembo
Copy link
Owner Author

amaembo commented Mar 17, 2016

Mars.1 was worse than latest Luna updates: many things which worked in Luna failed in Mars.1 (we even experienced ECJ stuck in endless loop). Mars.2 seems to be ok now. Dropping Luna means that not only me should upgrade, but also every user of StreamEx (at least if he wants to use this feature).

The into is better when you need complex combinators. For example, in the first (quite artificial) sample we have

c -> c.groupingBy(x -> x / 10, 
      c1 -> c1.flatMap(x -> StreamEx.of(x, x*2)).map(x -> "[" + x + "]").limit(5).toList())

Currently existing equivalent is

Collectors.groupingBy(x -> x / 10,
    MoreCollectors.flatMapping(x -> StreamEx.of(x, x*2),
        Collectors.mapping(x -> "[" + x + "]", MoreCollectors.head(5))))

I don't like such nesting, it looks ugly. Also it requires various static imports, which I don't like either. In CollectorBuilder version you don't need to specify types at all.

Current implementation is very early draft, so things might change (or I may drop this feature).

@lukaseder
Copy link

Dropping Luna means that not only me should upgrade, but also every user of StreamEx (at least if he wants to use this feature).

There's a difference between building StreamEx and using it. Maybe, the issues are internal only?

I see, thanks for the examples. Indeed, there's a certain painpoint. I still find Collectors very unintuitive to use, let alone compose. Looking forward to your future research!

@amaembo
Copy link
Owner Author

amaembo commented Mar 17, 2016

There's a difference between building StreamEx and using it. Maybe, the issues are internal only?

Nope. Internal issues are easy to fix: you can always introduce explicit type parameter, ugly unchecked cast or intermediate variables. Here, unfortunately, problems appear when you start using this API.

@lukaseder
Copy link

Very interesting. Have you considered profiling the issue and sending a bug report to Eclipse? If there's a low hanging fruit, they tend to fix things rather quickly in this area...

@amaembo
Copy link
Owner Author

amaembo commented Mar 17, 2016

As I said, it's moreless ok in Mars.2 and they will unlikely to backport fixes to Luna. I actually reported a couple of compiler bugs to Eclipse (1, 2).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants