Consider moving Seq implementations from Seq to SeqImpl, avoiding default methods where they aren't "defaults" but "trait implementations"

[lukaseder]

[stephenh]

Hey, just curious why you're wanting to avoid the default methods? Just wondering if you have a lesson learned I could pick up.

[lukaseder]

Just a matter of style. I've realised that suddenly, most implementation has moved to the interface, rather than the backing class and that feels kind of weird for a "default" method. Seq as it is now is a trait, not an interface.

I realise that the title is a bit too agressive. I'm undecided yet, whether this change should be made or not.

[stephenh]

Cool, that makes sense. Thanks for the insight!

[lukaseder]

@stephenh Hmm, just encountered another issue, proving my concerns to be justified:

I've implemented Collectable (#166), a common super type for Seq and the new Window. Both Seq and Window can produce streams, but Window is not a stream. Yet, as they can produce streams, they can both aggregate streams, too, hence the new common super type, where all the aggregations are declared.

Now, what happens to, for instance:

long count();

In Seq, it is inherited from Stream. In Collectable, I'd like to implement it as such:

default long count() {
    collect(Collectors.counting());
}

But because Seq now extends Stream and Collectable, I get a conflict because I'm inheriting the same method from two interfaces:

• abstract from Stream
• default from Collectable

Seq no longer compiles.

Default methods can be a very tricky thing from a backwards-compatibility point of view. It's dangerous to provide default methods, unless there's really no other way...