Vavr: CharSeq.split() returns an array & not a Seq

[danieldietrich]

In general, returning native arrays [] is not very helpful. We should revise our API.

[sajit]

Hello there. first time foray into trying to contribute to OSS project so please forgive if this sounds stupid. Just that I understand the requirement you want this method to return IndexedSeq <CharSeq>

[danieldietrich]

@sajit In general, the split result will be further processed.

We want to write:

CharSeq.of(csvLine).split(";").map(String::trim);

but having a result of type CharSeq[] we currently are forced to write

Vector.of(CharSeq.of(csvLine).split(";")).map(String::trim);

[danieldietrich]

Thanks guys! Seems @gde-vt also fixed this issue on a local branch :)

[danieldietrich]

Hey guys,

I've sleepless nights because this little change will break backward compatibility which may be a major issue regarding transitive library dependencies (e.g. two maven libs, one depends on the other, both use different Javaslang versions that are not compatible).

Such a change as this should

• either be made in a major release
• or we need to add an additional method without changing the original one

So we could defer this change to Javaslang 3.0.0 _or_ introduce new methods, e.g. splitSeq.

What do you think @sajit, @ruslansennov, @paplorinc ?

/cc @jest

[ruslansennov]

my vote for a new method splitSeq

[emmanueltouzery]

Maybe splitSeq and @Deprecated on split?

[danieldietrich]

I'm fighting with myself - targeting the most simple API possible, the new method's name would be split.

If we name it splitSeq and remove split in 3.0.0 we still have the problem that a third party lib that uses a 2.x version of Javaslang will not work any more if we use both in a new application, the third party lib and Javaslang 3.0.0. Maven for example will resolve the dependency conflict and choose Javaslang 3.0.0 over 2.x. The third party lib will then be forced to use Javaslang 3.0.0 at runtime, even if it is compiled against 2.x.

Now we are in backward-compatibility hell, like Java. We could keep the current split instead of deprecating and removing it. But from a birds-view this is a big problem. It would be like a stagnation in the evolution of the API and we would keep mistakes forever, duplicate similar methods like in this case and so on.

What we really want here is to _adjust_ the return type of split. Choosing a new name is the attempt to be backward compatible. Removing the current split will break backward compatibility (as stated above).

So I have another solution: We create a 3.0.0 branch and start the development of the next version right now. There we will keep the split method and adjust the return type. If methods are removed completely in the next version we will deprecate them in the current version. This is not the case here, so we may add a hint to the javadocs of the current version.

I think that it is essential for the health of Javaslang to be able to make major changes immediately instead of deferring them to the next major version using github issues. Eventually there will be so much changes that no-one is able to effort the time to play them back when it is time for a major update. Also we will not need any TODO markers. We will keep master and 3.0.0 branch in sync be merging frequently, ideally after each PR.

@paplorinc It should be easy to cut the splitSeq part of your PR #1296 and place it in the 3.0.0 branch.

[danieldietrich]

I created a 3.0.0 branch. The future is right ahead of us :-)

[paplorinc]

@danieldietrich, we could add a version hint to the package also, as https://commons.apache.org/proper/commons-lang did:

Note that Lang 3.0 (and subsequent versions) use a different package (org.apache.commons.lang3) than the previous versions (org.apache.commons.lang), allowing it to be used at the same time as an earlier versions.

Also, we could still add two versions now (@deprecated split and splitSeq) and have a single split in 3.0.

Opinions?

[danieldietrich]

This would be a solution to the problem but I think it is overkill. All versions of the API will be persistent forever. Bugs have to be fixed in all existing versions. We should no do that.

Maybe the Java 9 module system will come to the rescue?