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 2019 21:44

    danieldietrich on v1.0.0

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

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

    danieldietrich on v1.0.0

    Simplification (#2367) (compare)

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

    danieldietrich on travis-yml-fix

    Fixes malformed .travis.yml (compare)

  • Jan 31 2019 21:10
    codecov-io commented #2368
  • Jan 31 2019 21:10
    codecov-io commented #2368
  • Jan 31 2019 21:10
    codecov-io commented #2368
  • Jan 31 2019 21:10
    codecov-io commented #2368
  • Jan 31 2019 21:10
    codecov-io commented #2368
  • Jan 31 2019 20:51
    danieldietrich opened #2368
Aadi Deshpande
@cilquirm
thanks in advanced!
QP
@theqp

@danieldietrich thanks!
btw I have a non important suggestion and this has nothing to do with 1.0
do you think it makes sense to have a pipe function like this?
https://gist.github.com/theqp/bc8ca78ea961ef1dab6b85aa28a72952
the point of that I think

pipe(value, fn1, fn2);

is more readable than

constant(value).andThen(fn1).andThen(fn2).apply();

this idea is from fp-ts

Daniel Dietrich
@danieldietrich
Hi QP. Thanks for the suggestion. Pipe is syntactic sugar for ‘wrapped’ function calls. I suggest to give descriptive variable names instead and make calls explicit. That way no additional wrapper instances are created and debugging / stack traces are easier. Having proper variables makes more transparent what the code does.
Generally, I’m not a big fan of adding syntactic sugar. It mean GC/perf/mem overhead and a broader API surface area.
s/mean/means/
Btw - native syntactic sugar is nice but internal DSLs for syntactic sugar are a smell IMO.
QP
@theqp

Hi
I think in terms of overhead (each andThen creates a new lambda function) and debugging (you can step between function calls with just one call can see the result of all previous functions) is better compared to the second method.
With variable names I have two problems

  1. the scope of the result of the function becomes greater

    val result1 = fn1(value)
    val result2 = fn2(result1)
    /*both value and result1 can be passed here if types match*/
    val result3 = fn3(result2)
  2. it does not always provide extra information

    pipe(n, add(1),  times(3))
  3. java punishes using variables because you can only declare variables in a block and a block is not an expression and not even consistent:

     final Foo foo;
     {
         val added = add(n);
         foo = times(3);
     }
     // but in lambda we in use return
     n => {
         val added = add(n);
         return times(3);
     }
    
     // you may declare a method, but the definition almost as long as the method itself
     private static Foo getFoo(Bar n) {
         val added = add(n);
         return times(3);
     }
Aadi Deshpande
@cilquirm
another question: what is the state of vavr-kotlin. i. notice it's still at 0.9.2 and the main vavr library is at 1.0.0-alpha-3?
Daniel Dietrich
@danieldietrich
I think vavr-kotlin is unmaintained atm.
@theqp Vavr is aligned to Scala. Why baking pipe into it? It could be a library in its own. In the JavaScript ecosystem, small modules are common. Many packages only contain one function and have zero dependencies. I like that idea.
QP
@theqp
good point, you convinced me
nishantpandit
@nishantpandit
Hi Experts
I have the following data structure
List<Tuple2<Long, List<Integer>>>
So the data in there would resemble the following:
1, [1,2,3]
2, [1,2,3]
How do I create a list of this representation by flattening the List within the Tuple. So the final List would resemble the following List<Tuple2<Long, Integer>>
1,1
1,2
1,3
2,1
2,2
2,3
Thank you for your help
2 replies
Shayne Koestler
@skoestler

Hi all,
I've been trying to convert a List<Option<T>> to Option<List<T>> where the resulting option is defined when all of the options in the source are defined.
The following seems like it should work but I'm losing the type info, resulting in Option<List<Object>>

options.foldLeft(Option.of(List.empty()),
                 (reduction, current) -> reduction.flatMap(list -> current.map(list::append)))

I was wondering if anyone can help me figure out a way to do something equivalent without losing the type info.

Thanks in advance!

3 replies
Philipp Dargel
@chisui
Can someone explain why the vavr API should be aligned with the Scala collection API?
QP
@theqp
Because the point of Vavr is bringing scala APIs to java.
Philipp Dargel
@chisui

Hm, I was under the assumption that vavr was an independent functional collections project. The documentation doesn't make the connection clear either Everywhere I read scala in the docs there it only says that vavr is "greatly inspired by Scala" or Scala is used as an example. The only place where I could find this made explicit is in some github Issues where it was used as a justification for certain API decisions.

can you explain the motivation behind that?

QP
@theqp
Currently, vavr's collections are structured like this
https://www.vavr.io/vavr-docs/images/vavr-collections.png
this is a simplified verison of scala 2.12 collections
https://docs.scala-lang.org/resources/images/tour/collections-immutable-diagram.svg
vavr 1.0 will have a simpler structure based on scala 2.13 collections
there is no traversable in scala 2.13
Philipp Dargel
@chisui
My question is more why vavr tries to emulate the Scala API instead of going its own way. Java is another language than Scala after all. To be clear I have nothing against using Scala as inspiration and profiting from their learnings, but why are you trying to rigidly stick to it?
QP
@theqp
It's going it's on way inspired by scala
e.g. in Scala there is no List.of, there is List.apply
btw I am not the maintainer of this project, just having my assumptions as a scala developer
Philipp Dargel
@chisui
Ok, the issues where differences to the Scala API are used as a reason not to change the API are 5 years old.
Thank you @theqp
QP
@theqp
a better way to say this is that Vavr is bringing a part of Scala's API to Java in a Java idiomatic way.
stating that would make no sense because people would think that vavr is for scala developers who are forced to program in java
vavr is for everyone who misses a more functional API from java which is simple to use
Philipp Dargel
@chisui
@danieldietrich What is the status of the Issue organisation
Daniel Dietrich
@danieldietrich
I track the issues and invest time when my time does allow it.
I‘m thinking about a sponsor model. It would help me and you to react near time.
Currently, I do it in my spare free time (I have a wife and 5 children at home, a challenging daylight job, more than one open source project and diverse side-cars 🤯). Opening the organization/issues for sponsors only would ensure that Vavr will be supported long term for companies that use Vavr in production. I think that is a good idea.
3 replies
Daniel Dietrich
@danieldietrich
Thank you for the kind words 😊
Gerard Bosch
@gerardbosch
You're welcome! I've learned a lot since I started using Vavr :D
Gerard Bosch
@gerardbosch
Hi all! Hi @pivovarit I have a question: Will assertj-vavr be compatible (as-is) in its current version with the upcoming Vavr 1? I've just faced right now assertj-vavr and I would like to use it. Is it actively developed/maintained? I'm wondering if Vavr v1 gets released, will assertj-vavr keep compatible? Thx!! :)
(Maybe anyone else knows the answer as well, hehe)
Daniel Dietrich
@danieldietrich
Hi! 👋 The chance is high that assertj-vavr needs to be updated because Vavr 1 will be a backw-incompat release. However, the collections will be kept pretty stable. The Either, Option and Try API will be uncluttered...
Gerard Bosch
@gerardbosch
Thanks Daniel!
I guess then that assertions in collections will then keep working as is in assertj-vavr:0.2.0, as collections are not supposed to change (List, Stream, etc)
Is that right?
Daniel Dietrich
@danieldietrich
The probability is high but I must admit that I don't know the details of assertj-vavr...
Gerard Bosch
@gerardbosch
Well I see that the assertion is performed over Java Iterable: public static <ELEMENT> IterableAssert<ELEMENT> assertThat(Iterable<? extends ELEMENT> actual) {
So no need for specific assertj-vavr in this case
Gerard Bosch
@gerardbosch
I see assertj-vavr offers a more specialized version using Seq:
public static <VALUE> SeqAssert<VALUE> assertThat(Seq<VALUE> actual) {
Kristoffer Opsahl
@kriops_gitlab
Hi, can somebody point me to a resource for understanding why foo is a Stringwhile bar is a HashMap<String, String>? I expected both matches to return the HashMap<String, String> type.
String foo = Match("A").of(
          Case($(Predicate.isEqual("B")), HashMap.of("X", "Y")),
          Case($(), HashMap.empty())
      );

HashMap<String, String> bar = Match("A").of(
          Case($(Predicate.isEqual("B")), HashMap.empty()),
          Case($(), HashMap.empty())
      );
Gerard Bosch
@gerardbosch
Do the first expression foo compile? :flushed:
Kristoffer Opsahl
@kriops_gitlab
The entire snippet compiles!
Kristoffer Opsahl
@kriops_gitlab
Replacing the value with a lambda that returns it solves it, though I don't understand why. "Solution":
HashMap<String, String> bar = Match("A").of(
          Case($(Predicate.isEqual("B")), str -> HashMap.of("X", "Y")),
          Case($(), HashMap.empty())
      );
Gerard Bosch
@gerardbosch
It looks strange but I'm not an expert. Maybe @danieldietrich has the explanation.
Joe Pallas
@jpallas
HashMap is a Function, so Case is picking Case(Pattern0<T> pattern, Function<? super T, ? extends R> f) rather than Case(Pattern0<T> pattern, R retVal)
Daniel Dietrich
@danieldietrich
Thx! 👍 An explicit cast (HasMap) HashMap.empty() + generics would solve it but looks a bit noisy