Closed danieldietrich closed 5 years ago
Vavr 0.10.0 will contain the following changes:
* (!) Collections do not extend (Partial)Function anymore. See PR #2267
* Fixed return types of some SortedMap methods to return SortedMap instead of Map
- put(Tuple2, BiFunction)
- put(Object, Object, BiFunction)
- replace(Object, Object, Object)
- replaceAll(BiFunction)
- replaceValue(Object, Object)
* Widened Future arguments from ExecutorService to Executor
* Widened return type of HashMap.values() (before: Stream, after: Seq)
* Removed internal class Lambda from the (Checked)Function type hierarchy. It broke Scala apps, see #2337
* Some internal classes of the auxiliary types changed (should no matter)
Full report:
Note: the backw'incompat changes to (Priority)Queue.dropUntil(Predicate) look like false-positives to me.
We will introduce new functional interfaces for Future.run().
Before (cryptic):
static <T> Future<T> join(CheckedConsumer<Predicate<Try<? extends T>>> computation) { ... }
After (human readable):
static <T> Future<T> run(Task<? extends T> task) { ... }
where
@FunctionalInterface
public interface Task<T> {
void run(Complete<? extends T> complete) throws Throwable; // maybe Exception instead?
}
@FunctionalInterface
public interface Complete<T> {
void with(Try<? extends T> value);
}
Usage:
Future.run(complete -> {
// do some heavy work here
if (getMood() == Mood.GOOD) {
complete.with(Try.success("😊"));
} else {
complete.with(Try.failure(new BadMoodException());
}
});
Note: The new Future.run() API is good for many cases we needed Promise before. E.g. when having nested Futures:
interface Future<T> {
Future<T> fallbackTo(Future<? extends T> that) {
return run(executor(), complete ->
onComplete(res -> {
if (res.isSuccess()) {
complete.with(res);
} else {
that.onComplete(alt -> complete.with(alt.isSuccess() ? alt : res));
}
})
);
}
}
There is still one use-case for Promise we did not solve with the new Future.run() API: Passing the complete function to the outside of the run() method scope. See #2086
I ran the unit tests of v0.9.3 with the upcoming v0.10.0 classes. It boils down to:
Traversable
interface needs a default impl for reject(Predicate)
(see #2157). It is semantically equivalent to filter(predicate.negate())
io.vavr.control.HashCodes
and deprecate it (see #2275)(Partial)Function*
and withDefault(*)
(see #2249, #2267)The all should compile fine again.
These are the compile errors (work in progress):
✅ All unit tests of v0.9.3 run with v0.10.0 (!)
These are the crucial changes from v0.9.3 -> v0.10.0 regarding backward compatibility. I see a green light regarding the release.
Caution: it needs to be interpreted correctly!
Thank you very much, Daniel!
Since I discovered your library 9 months ago my way of doing things completly changed. So thanks for your great job and thanks for this update.
Thank you for the kind words @PHaroZ !
Progress:
TODO
in the code[x] Inform Vavr sub-projects and Oliver Drotbohm (Spring Data Vavr integration)
Currently I see the following challenge:
Starting with Release 0.9.0, the master diverged from our releases in the following way:
The latter hinders us from
In order to solve this knot, I will clean up master the way that v1.0 related, backward incompatible changes will be stashed and removed from master.
Further more I will merge all of the following commits from the master branch into the release branch that make it into the next minor release v0.10.0. This allows to go on with development of v0.10.1 or v0.11.0 until v1.0.0 is ready.
release branch (maintenance)
These are the current 0.9.0 to 0.9.3 commits (cherry-picked from master and edited to be backward compatible):
master branch (development)
I replayed the master history of 0.9.0 up to now (10.01.2019) and moved backward incompatible changes to the stash-pre-0.10.0 branch.