Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 21:44

    danieldietrich on v1.0.0

    Fixes malformed .travis.yml (#2… (compare)

  • Jan 31 21:44
    danieldietrich closed #2369
  • Jan 31 21:31
    codecov-io commented #2369
  • Jan 31 21:31
    codecov-io commented #2369
  • Jan 31 21:31
    codecov-io commented #2369
  • Jan 31 21:18

    danieldietrich on v1.0.0

    Simplification (#2367) (compare)

  • Jan 31 21:18
    danieldietrich closed #2367
  • Jan 31 21:18
    danieldietrich closed #2368
  • Jan 31 21:18
    danieldietrich labeled #2368
  • Jan 31 21:14
    danieldietrich labeled #2369
  • Jan 31 21:14
    danieldietrich labeled #2369
  • Jan 31 21:14
    danieldietrich milestoned #2369
  • Jan 31 21:14
    danieldietrich opened #2369
  • Jan 31 21:14

    danieldietrich on travis-yml-fix

    Fixes malformed .travis.yml (compare)

  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 21:10
    codecov-io commented #2368
  • Jan 31 20:51
    danieldietrich opened #2368
Bob Glamm
@glammr1
Going from F<G<X>> to G<F<X>> is common enough that sequence (and traverse, in systems that support it) are provided to perform that transformation in both Kotlin-Arrow and Scala-Cats/Cats-Effect
Gerard Bosch
@gerardbosch
Very nice! Maybe the only difference is that Future.sequence creates an additional instance of Future
Thanks for your help @glammr1 :))
Bob Glamm
@glammr1
np!
Alexander Samsig
@Asamsig
What are you guys doing for pattern matching, are you using the to be removed pattern matching in Vavr?
Bob Glamm
@glammr1
I've used that pattern matching, but these days for pattern matching I'm using Kotlin's with :D
Gerard Bosch
@gerardbosch

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)

(Both snippets do the same and return a Vavr List)
Bob Glamm
@glammr1
   return io.vavr.collection.List.ofAll(accountsClient.getAccounts("XXXX", false).getBody().getAccountList())
        .map(mapper::map);
Gerard Bosch
@gerardbosch
ups, sure!
You're right, there's still a fully qualified name there, but I think its less painful
Bob Glamm
@glammr1
Yeah, that's the toughest part about Vavr's collections
Gerard Bosch
@gerardbosch
Auch, I realize that qualifying Vavr List is not even required. Thanx!!
return List.ofAll(accountsClient.getAccounts("DV", false).getBody().getAccountList()) .map(mapper::map);
Bob Glamm
@glammr1
Java really needs import io.vavr.collection.List as VList; syntax IMO
Gerard Bosch
@gerardbosch
Yesss... Is the import as available in latest Java versions? I'm stuck at Java8 :-/
Bob Glamm
@glammr1
I do not think that syntax is available in any Java version yet
Gerard Bosch
@gerardbosch
Maybe I was also going back to the point of yesterday about if using Option to merely chain operations (mainly map) is a misuse/overkill... If anyone else would like to give their thoughts :)
Anyway thanks again @glammr1
Bob Glamm
@glammr1
np! FWIW I would have a hard time accepting a PR using Option solely for the purpose of chaining operations
As for a concrete reason why, the second example you showed above is actually functionally different from the first example since .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.)
Assuming I am reading the code correctly, anyway
Gerard Bosch
@gerardbosch
I also have a mapper method for single element: MyAccount map(Account)
Gerard Bosch
@gerardbosch

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!

Fabio B. Silva
@FabioBatSilva
Hi.. Is there a better way to write something like this ? :
    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));
    }
Nándor Előd Fekete
@nfekete
how about this:
public static Function1<String[], String> say() {
    return (a) -> String.format("Hello %s %s", a[0], a[1]);
}
Fabio B. Silva
@FabioBatSilva
haha.. just a example..
v1 and v2 are functions that share the same argument..
i'm looking for a way apply a argument to v1 and v2 and then use the result of both in a third func
Nándor Előd Fekete
@nfekete
lol, okay
Nándor Előd Fekete
@nfekete
@FabioBatSilva so which variables are already defined and which ones you need a "better way to define"?
Fabio B. Silva
@FabioBatSilva
I think this is a better representation :
    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);
    }
I'm trying to figure out if there is a better way of invoking f1 and f2 and passing the results to f3
Nándor Előd Fekete
@nfekete

anyways, you could do

return a -> Tuple.of(a, a)
    .map(v1, v1)
    .apply(cheers);

or

return a -> Tuple.of(a, a)
    .map1(v1)
    .map2(v2)
    .apply(cheers);

but I'm not sure why would you do something less efficient and probably less readable like this instead your original code

Fabio B. Silva
@FabioBatSilva
Some thin like curried or compose.. but where the argument is a func
Nándor Előd Fekete
@nfekete
I think the original code is best in this case, no need to overcomplicate things.
Bob Glamm
@glammr1
Strictly speaking it's probably Applicative but I agree with @nfekete
Fabio B. Silva
@FabioBatSilva

Makes sense..

Thanks ! @glammr1 / @nfekete

Choi Sum
@CsxUk_twitter
Hi all, though you might to know. A few months ago I was talking to some colleagues to evangelize vavr within our organization. At that time they were committed to using RxJava, which I thought was over complex....hey presto a few months down the line and they have switched to vavr because it's so much simpler!!

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)

Alexander Samsig
@Asamsig
You should be able to use mapTry, and then not wrap the new function calls in Try.
Choi Sum
@CsxUk_twitter
@Asamsig perfect, thank you. Not sure how I missed this :)
Tapio Niemelä
@NiemelaTapio_twitter

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

Daniel Dietrich
@danieldietrich
Interesting, that might be a bug! Could you please file an issue?
Choi Sum
@CsxUk_twitter
Not sure if this is the right place, I am using the Vavr/-Jackson module to return a ResponseEntity from a Spring Rest controller....I'm finding it doesn't seem to work when I return a ResponseEntity<io.vavr.List> or ResponseEntity<io.vavr.map>, although it does work if the io.vavr.collection is contained instead of being the outer wrapper.
Choi Sum
@CsxUk_twitter
scratch that...I don't have vavrmodule registered anywhere
Tapio Niemelä
@NiemelaTapio_twitter
Hi, just a general question (please direct me to correct forum if this isn't the correct place). Is there any hope to get liftA2 into Try and Option. For try method would be something like
Try<V> liftA2(Try<U> other, CheckedFunction2<T,U,V> mapper)
Daniel Dietrich
@danieldietrich
@NiemelaTapio_twitter thanks for your question! Probably not. Our strategy is to align tightly to native Scala. There you don't find such a method. My personal opinion is that such syntactic sugar widens our API surface area in an unhealthy way. Especially helper methods which require some kind of arity are a big pita in Java. Other users could askfor liftA3, liftA4, ... liftA8 etc.
// 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);
Maybe you just lift the mapper once (like in solution 2).
Tapio Niemelä
@NiemelaTapio_twitter
@danieldietrich ok, thanks for the answer and suggested "work-around"
Daniel Dietrich
@danieldietrich
@NiemelaTapio_twitter 👍🏼