Hi, I have just started upgrading Arrow to 1.2.0. ...

# arrow

[dnowak]

Hi, I have just started upgrading Arrow to 1.2.0. The most work was with replacing Validated. Everything works fine.
The only thing I’m really concerned with is the removal of “fluent API”. It is suggested to replace, for example, sequenceEither method with its “inline” version:

let { l -> either<E, List<A>> { l.bindAll() } }

Instead of a well-understood function name now I have to “parse” the code to find out what it is doing. The worse thing is that the “body” can be formatted in many ways - like

.let { l ->
                    either<FindProfileError, List<ProfileEntry>> {
                        l.bindAll()
                    }
                }

making it even harder to understand the code compared to just one line:

.sequenceEither()

Why do you think that DSL version is better and should be preferred?

[simon.vergauwen]

Hey Dariusz,

There are a couple of reason for doing this.
1. DSL offers what we think is more idiomatic syntax map vs traverse.
2. We wanted to reduce duplication in the API, and decrease the API surface (in order to reduce confusion and reduce learning curve)
3. Decrease the binary size
We imagine that everyone is already working within the DSL, and in the future context receivers. In those case there is no need for traverse or even bind.

Sadly ReplaceWith is not that great. It cannot detect wheter you're already in a DSL, and worse with the let call it fails to automatically refactor. The resulting code can actually be simpler that what is described in ReplaceWith.

That all being said, I guess we might want to add it within the deprecation message. If you prefer fluent API, Quiver is going to add adopt traverse & zip and potentially some other fluent APIs.

I mentioned it in the migration guide, https://arrow-kt.io/learn/quickstart/migration/#either-dsl-effect--effectscope. In the info block.

So you can potentially also just ignore these deprecation warnings, and depend on Quiver when finally moving to 2.0.

I'm also touching upon this topic in my talk on Thursday on KotlinConf, but I'd more than happy to answer any more questions you have. (Cannot share my slide yet early 😜)

[simon.vergauwen]

Thanks for testing 1.2.0-RC, and providing feedback 🙏 The decision to deprecate traverse was IMO one of the hardest, but since Quiver will be filling this gap I think it's the right decision for core.

We also have this new eco-system page which should make it easy to find, and explore these other libraries. https://arrow-kt.io/libraries/

[dnowak]

Keeping the API small makes sense. Thank you for keeping old good function in Quiver 🙂.