danieldietrich on v1.0.0
Fixes malformed .travis.yml (#2… (compare)
danieldietrich on v1.0.0
Simplification (#2367) (compare)
danieldietrich on travis-yml-fix
Fixes malformed .travis.yml (compare)
Hello,
For the kind of usual constructs like the following, which one do you think is more clear/convenient? This is just a small example of something usual.
Option 1:
public io.vavr.collection.List<MyAccount> retrieveAccounts() {
final List<AccountResource> accounts = accountsClient.getAccounts("XXXX", false)
.getBody().getAccountList();
final List<MyAccount> myAccounts = mapper.map(accounts);
return io.vavr.collection.List.ofAll(myAccounts);
}
Option 2:
public List<MyAccount> retrieveAccounts() {
return Option(accountsClient.getAccounts("XXXX", false).getBody().getAccountList())
.map(mapper::map)
.map(List::ofAll)
.get();
}
Please, notice subtle differences option 1 presents, such as the usage of Fully Qualified Names for Vavr.
Is using Option
in such way an overkill/misuse?? (I could replace Option
by Some
in this example, to clearly state that there is no place for nullability, just using it to pipe operations)
.map(mapper::map)
is operating on Option<Y>
instead of List<X>
, where Y = List<MyAccount>
. (mapper::map
has to be constructed to take a List<MyAccount>
parameter instead of a MyAccount
parameter.)
Hello! Why is this function deprecated on Map (Vavr 0.10.2)? There is no deprecation note in the Javadoc:
@Deprecated
@Override
default V apply(K key) {
return get(key).getOrElseThrow(() -> new NoSuchElementException(String.valueOf(key)));
}
Is there the recommended alternative Map.get(key).get()
when I'm confident that there is an entry for such key on the map/or I want to assume the exception? I found map.apply(key)
neat, but is marked as deprecated.
Any thoughts? Thanks!
public static Function1<String[], String> say() {
final Function1<String[], String> v1 = (a) -> a[0];
final Function1<String[], String> v2 = (a) -> a[1];
final Function2<String, String, String> cheers = (s1, s2) -> String.format("Hello %s %s", s1 , s2);
return (a) -> cheers.apply(v1.apply(a) , v2.apply(a));
}
v1
and v2
are functions that share the same argument..
public static Function1<String[], String> say() {
final Function1<String[], String> f1 = new Func1();
final Function1<String[], String> f2 = new Func2();
final Function2<String, String, String> f3 = new Func3();
return (a) -> f3.apply(f1.apply(a), f2.apply(a));
}
public static void main(String[] args) {
say().apply(args);
}
f1
and f2
and passing the results to f3
And one question from me, if I may...I find myself writing this construct quite a few times when dealing with IO
Try.sucess("some string")
.flatMap(str -> Try.of(() -> ioFunc(str))
.flatMap(result -> Try.of(() -> otherIoFunc(str))
...
My question is whether there is a simplify this construct (I tried flatMapTry but compiler complains, unless I missed something)
Hi all
Is there bug in the API-documentation in Traversable::sliding(int size, int step) ?
According to the documentation
[1,2,3,4].sliding(5,3) should give [[1,2,3,4],[4]]
But
Iterator<List<Integer>> ints = List.of(1,2,3,4).sliding(5,3);
System.out.println(ints.next()); //List(1, 2, 3, 4)
System.out.println(ints.next()); // throws NoSuchElementException
throws java.util.NoSuchElementException: next() on empty iterator
// your suggestion
var tryV = tryT.liftA2(tryU, mapper);
// existing solution 1: wrap call in a Try
var tryV = Try.of(() => mapper.apply(tryT, tryU));
// existing solution 2: lift the mapper
Function<T, U, Try<V> liftedMapper = CheckedFunction2.liftTry(mapper);
var tryV = liftedMapper.apply(tryT, tryU);
// future solution 3: for-comprehension
// (unfortunately that currently does not work because For.yield takes a BiFunction)
var tryV = For(tryT, tryU).yield(mapper);