Some minor fixes and additions

[techsy730]

• Fix BigList's default setElements function using the size of the outer array instead of the proper BigArrays.length.
• Add an example of intStream usage to overview.html
• Update overview.html examples to show off the new of static factory methods.

[vigna]

If I'm understanding correctly, you slightly deviated from the JDK's design in the sense that collector methods are in collection classes, and not in a Collectors class. Am I right?

[techsy730]

Correct. I didn't want to add yet another new generated class, and in Guava the collector methods are on the ImmutableX types, so it has precedence.

[vigna]

OK. I see an advantage here in that if you have several implementation of the same idea (e.g., several type of sets) you have a more clear distinction. But this must be documented very well—people will look for IntCollectors. I don't have a good feeling about this. Let me think.

[incaseoftrouble]

I think the "JDK" way is preferable. For example, having IntCollectors.set() and IntCollectors.unmodifiableSet() as "general purpose". Besides alignment with JDK, you have the freedom to change the backing implementation or even dynamically choose it. FWIW, the "generic" collector could forward to specific stuff like IntOpenHashSet.collector()?

[vigna]

Well, the problem is that, in fact, we cannot really have type-specific collectors unless we wanna add 9³ interfaces, and possibly as many abstract implementations, which I'm not sure I wanna do, as Collectors have three parameters.

The way @techsy730 implemented collection of streams (by methods in the collection classes) certainly reduces flexibility, and breaks partially the fluent API, but at the same time saves us from having a gigantic amount of new interfaces and classes.

I'll document this in the Javadoc, explaining the choice. It is of course a pity, as many functionalities of collectors would be much faster implemented in a primitive way. One possibility might be that of allowing only collectors whose last two parameters are the same (i.e., the data and the accumulator are of the same type). That would be bearable.

[techsy730]

Sorry for the necro-post, but the real deal breaker for things like IntCollector is that none of IntStream, LongStream, and DoubleStream have a collect method that takes an equivalent style interface like Collector.

So we would have to either re-implement the primitive Stream types (not happening). Or add such a method to generated subinterface of IntStream et al, that adds that method with a reasonable default implementation.

While this wouldn't be too bad in the sequential() single-threaded case, it would be a nightmare for parallel() streams.