by

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
JunHyung Lim
@EntryPointKR
And I'm not sure the way using flatMap() and map() is better than just use if(uuidEither.isLeft()) return Option.of("Wrong usage")
Bob Glamm
@glammr1
For(args.apply(1).map(Arguments.UID), args.apply(2).map(Arguments.DURATION)).yield(uuidEither, durationEither -> ...)
Samuel Cox
@crankydillo
Hi, I think it is, but need to double check.. Is vavr’s Map a persistent collection?
Nándor Előd Fekete
@nfekete
@crankydillo yes. In fact, all vavr collections are persistent
Samuel Cox
@crankydillo
I was just about to ask that:) Many thanks! The doc confused me just a small amount. I think you go into detail about 3 of them (https://www.vavr.io/vavr-docs/#_functional_data_structures), but it scared me that the others might not be. I didn’t read your entire doc, but you might want to verify it makes that clear that all are. Then again, it’s probably just me:)
Daniel Dietrich
@danieldietrich
Thanks! The docs will get a refresh for v1.0
Samuel Cox
@crankydillo
Cool. Thanks for the awesome library. I’ve come back to Java after almost 10 years in Scala. Your lib is helping quite a bit:)
Daniel Dietrich
@danieldietrich
Great to hear that!
JunHyung Lim
@EntryPointKR
Francis Toth
@francistoth_twitter
Hi all, I am looking for an equivalent of sequence for Either. So something that goes from a List<Either<E, A>> to an Either<E, List<A>>. Is that something implemented in vavr?
Francis Toth
@francistoth_twitter
this basically:
    public static <L, R> Function<List<Either<L, R>>, Either<L, List<R>>> sequence() {
        return es -> es.foldLeft(right(empty()), (e0, e1) -> e0.flatMap(rs -> e1.map(rs::append)));
    }
Bob Glamm
@glammr1
That looks an awful lot like Validated / Validation
Nándor Előd Fekete
@nfekete
@francistoth_twitter isn't Either.sequenceRight what you are looking for?
VKorelsky
@VKorelsky

Hi everyone,
My team is considering using Vavr in a new production service - we were just wondering, how well maintained is this library? Looking at the GitHub commits it seems active, although I can see that the last release was back in August. Will the library be supported long term?

Thanks!

Daniel Dietrich
@danieldietrich
Hi @VKorelsky, yes, the library is maintained. It is considered stable, although it is a 0.x release. The upcoming 1.0 will have some backward incompatible changes but it will also offer a migration path.
The users are happy so far. Not all feature requests are implemented because we keep the API surface area small. During the last months, there weren't many bug reports (which is a good sign).
There are two upcoming releases planned, a major one (which is really overdue) and one feature backport to the the current version.
VKorelsky
@VKorelsky
Hi Daniel, thanks for your reply. Do you know when version 1.0 is scheduled to be released?
Daniel Dietrich
@danieldietrich

I stopped to plan dates, very much like other teams, for example at Facebook.

But I can tell you what I want to change. Option/Try and Either method names will be aligned to the Scala counterparts. I will prepare the classes to be used with Java’s native pattern matching and the deprecations will be mostly removed.

Daniel Dietrich
@danieldietrich
🤔°oO( If I would do Vavr fulltime, I would ship 1.0 next week. But I do Vavr in my spare time by night and during the weekends. And I have a wife and 5 children... I would love to have the freedom / the financial backup to work on Vavr on a regular daylight basis. )
Gerard Bosch
@gerardbosch
Hello Daniel, will the Vavr 1.0 targeted to a specific Java version or minimum version? Will still work on Java8? or will be targeted to Java 14 to leverage Java's pattern matching? This is just to know, thx!! :)
Daniel Dietrich
@danieldietrich
Hi Gerard, Vavr 1.0 will still target Java 8. It is too early to jump on a new version.
VKorelsky
@VKorelsky
Fair points! Thanks for spending time on this :)
Daniel Dietrich
@danieldietrich
Clarification: everyone should jump on a new Java version. But Vavr will still run on Java 8.
Gerard Bosch
@gerardbosch
:joy:
Bob Glamm
@glammr1
I whipped up a JavaScript interop project yesterday using Java 14 and immediately tried to use local variable type inference for class-level fields
Needless to say I was sorely disappointed
Daniel Dietrich
@danieldietrich
yes. it is also a pitty that function types cannot be inferred. this is because Java language architects decided to use Functional interface instead of ‚native‘ function types: () -> 1 is of type () -> int
compared to that, typescript did really a fresh take on nominal typing
in kotlin and scala, functions are also first class citizens
but I don‘t want to gripe about java‘s take on it, we work with what we have, it is just a little bit more verbose
Julian
@JulianFeinauer
I have to admit I'm still unsure whether type inference is a good thing after all
Most code is write once, ready many.. So why save a second on writing and spend minutes while reading... Each time...
But that's just IMHO
Gerard Bosch
@gerardbosch
I guess nowadays IDEs are providing the required highlights on variable types (and they also write the type of variables by themselves). But I feel on your side at some extent.
Julian
@JulianFeinauer
Yes but it's the same to write. I don't know why I wrote a type for declaration the list time...
Bob Glamm
@glammr1
I'm flexible on type annotations: for complex types I find them useful to include to ease reading, but at the same time if I have complex types I know I probably have to simplify them or alias them to make them less unreadable.
Then if I simplify the types, usually the code gets simpler and I don't need as many type annotations anymore
Julian
@JulianFeinauer
Yes good point
Daniel Dietrich
@danieldietrich

My problem with readability in Java is that types are prefixed instead of being suffixed:

// types are prefixed
Function<Integer, String> myFunction = String::valueOf;
int myInt = 10;
CompletableFuture<Optional<String>> myCompletableFuture = null;

// types are suffixed
myFunction: Function<Integer, String> = String::valueOf;
myInt: int = 10;
myCompletableFuture: CompletableFuture<Optional<String>> = null;

In languages that suffix the types, it is more natural to just leave them away, if the context is clear.

// explicit types
var myFunction: Function<Integer, String> = String::valueOf;
var myInt: int = 10;
var myCompletableFuture: CompletableFuture<Optional<String>> = null;

// inferred types
var myFunction = String::valueOf; // type inference does NOT work for lambdas and method references
var myInt = 10;
var myCompletableFuture = null;

In languages like JS / TS, we pass around JSON objects and transform/consume them using functions.
Again, in that case it is natural leave the type away:

// explicit type
const person: { name: string, age: number } = { name: "Piet", age: 33 }

// inferred type
const person: { name: "Piet", age: 33 }

I think Java is a bit more verbose with its types. Therefore code with inferred types is a little bit harder to read.
Sometimes, I experience the same with JS /TS code and tend to add types for clarity.

Daniel Dietrich
@danieldietrich
Same for functions. It looks more natural to have the same notion for types:
type Person = { name: string, age: number }

// explicit type
const birthday: (p: Person) => Person = (p) => {...p, age: p.age + 1}

// inferred type
const birthday = (p: Person) => {...p, age: p + 1}
Julian
@JulianFeinauer
I agree with you
I just dislike the general „type inference is the best thing in the world and writing types is such a waste“-movement
Daniel Dietrich
@danieldietrich
tabs vs. spaces is so yesterday.
type inference vs explicit types is the new thing 🙃
Julian
@JulianFeinauer
haha, yes, indeed
Görge Albrecht
@goerge
@danieldietrich I wonder whether io.vavr.API will stay as is in Vavr 1.0. Won't this violate java modules system as API imports from both control and collection? (I didn't find any Github issue regarding this topic and Gitter is hard to search)
Daniel Dietrich
@danieldietrich
control and collection won‘t be modules because of that. But we will have separate io.vavr.match, io.vavr.controlx (containing Validation) and io.vavr.collectionx (containing Multi*Map/Set, BitSet, PriorityQueue, Tree)
the io.vavr.API will only support core types. Especially the Match API will move elsewhere. I suggest to adapt native pattern matching over time! Even if it will not support every use case.
I‘m thinking about introducing new namespaces in order to don‘t break older versions. E.g. io.vavr1. Next major release will be io.vavr2 etc.
Daniel Dietrich
@danieldietrich
I'm aware that it would be most appreciated if all stays compatible with Vavr 0.10 and it would be all about new features, better performance etc.
But Vavr 1.0 will be about simplifying the API and fixing the type hierarchy.
Görge Albrecht
@goerge
Thanks. I conclude that some kind of API class will still be available though maybe stripped by API.Match, API.Case etc. I totally support your efforts to stream line the vavr api in general. I'm fine with moving things around ;-)
Daniel Dietrich
@danieldietrich
Exactly like you described! Personally I guess that most of the users will even not recognize that something has changed :)