https://kotlinlang.org
Join Slack
Release <https://github.com/orbit-mvi/orbit-mvi/releases/tag/9.0.0> migration guide feedback
# orbit-mvi
t
1. please be more explicit about which functions are affected, i.e. 
import org.orbitmvi.orbit.syntax.simple.*
2. 
org.orbitmvi.orbit.syntax.simple.SimpleSyntax
cannot be "just removed", because it's now called 
org.orbitmvi.orbit.syntax.Syntax
3. 
org.orbitmvi.orbit.syntax.simple.SimpleContext
cannot be "just removed", because it's now called 
org.orbitmvi.orbit.syntax.IntentContext
4. It was unclear where functions went: "up" (e.g. Syntax.reduce, but ContainerHost.intent).
With all this, migration was still "trivial", but it would be nice to get a before/after for other users as my project had only 1 utility class (logging) and 1 test and yet I faced all the above. Because there was no deprecation cycle (with 
ReplaceWith
), a table similar to what's in ktlint's release notes would go a long way.
m
Ack, duly noted and apologies. I kinda broke my own rules of releasing a prerelease and testing on my own project. Will provide a migration guide on Monday 👍
Thank you for the feedback
👍 1
FWIW we're going to introduce the binary compatibility checker into the build pipeline and will try our best to avoid annoying breaking changes in the future
t
major is major 🙂
m
t
Nice!
Re reified, is there a chance a user would want to dynamically calculate the class object? With reified only API, this is not possible.
m
Sounds like a niche use case, but I'm not opposed to supporting both
t
I don't have a use case, just noticed in the table.
👍 1
m
the purpose of the API is mostly to run things only if in a certain state
so we'll be relying on a type known at compile time usually 🙂
t
What it could prevent: one could know a super type at compile time, and decide the concrete at runtime.
👍 1
5 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by