🎉 Add Either class, in Kotlin

[luoser]

heck yes!

Say hello to our first Kotlin class. 🤸‍♂️

what

I ran into this 🤔 💭 moment when setting up our code for native comment support on project updates: since we have comments for either projects or updates, and Swift in fact handles this with its own Either type, 💡, add one to android. Maybe even add it in Kotlin.

Things to note:

• companion object allows for us to access left and right as static methods, while keeping our private constructor
  • this ensures that Either objects cannot be created with both values, i.e.

  new Either<Int, String>(1, "don't do this!")

  • [EDIT] Using sealed class instead, thanks for the suggestion @stephencelis
• != null checks are repeated rather than the defined isLeft and isRight functions to satisfy compiler optional warnings ¯_(ツ)_/¯
• I stopped after adding mapLeft due to time, but coming soon will be flatten(), flatMap(), etc. when we have more time to figure out how to define these functions elegantly without enums

s/o to @mbrandonw for helping me explore this, and @christopherwright for the continued moral support

[stephencelis]

What do you think of using sealed classes for this?

sealed class Either<out L, out R> {
  class Left<out L, out R>(val left: L) : Either<L, R>() {
    ...
  }
  class Right<out L, out R>(val right: R) : Either<L, R>() {
    ...
  }
}

Either.Left("Error!")
Either.Right(1)

when(either) {
  is Left -> either.left
  is Right -> either.right
}

Seems to be a common pattern for tagged unions in Kotlin, and prevents even the private ability of instantiating an invalid type.

[luoser]

[mbrandonw]

amazing! the syntax is a bit funky, but i'll get used to it.

just a few questions...

[mbrandonw]

should everything be marked as public?

[luoser]

for posterity public is the default modifier in Kotlin so we get redundant warnings

[mbrandonw]

are the parens optional? should it not be intOrString.right()?

[christopherwright]

Looks great!

[pakoito]

I have my reservations about the way Either is implemented. The use of null types, isLeft() and isRight() allows for a scape hatch from static analysis which should be enforced instead. The encoding to enforce should is similar to the Java version seen here https://github.com/pakoito/RxSealedUnions

EDIT: okay, I'm late to the discussion and it'd be great if you gave that project's README a look and gave me an opinion.

[stephencelis]

@pakoito Not sure I follow. Could you clarify? This is just a starting point and the API is based on our Swift implementation. The only nullables here come from the left() and right() fold operations, which we don't typically use outside of tests. In general we use either(ifLeft, ifRight) for folding.

EDIT: We also don't use isLeft() or isRight() in practice:

• https://github.com/kickstarter/ios-oss/search?utf8=✓&q=isLeft&type=Code
• https://github.com/kickstarter/ios-oss/search?utf8=✓&q=isRight&type=Code

We could very well get rid of these interfaces.

[pakoito]

Fair enough them, but I'd remove all of them.

[stephencelis]

For what it's worth, our implementations are all based on Haskell's Data.Either, which also implement these functions. The types should be statically sound, but if we're missing anything, let us know!

[pakoito]

map, mapRight, isLeft and isRight can all be expressed in terms of either(). I didn't know about Haskell's implementation, so probably I am being too anal about it.

[Miha-x64]

Shouldn't this be inline? Also, this function may be called apply.

[d3xter]

I'd use Nothing as the unused type in Left and Right,
e.g. class Left< out L >(internal val left: L) : Either<L, Nothing>()

This allows to create an instance of Left with val left = Either.Left(15) without specifying the right type.

fun foo() = when {
1 == 1 -> Either.Left(1)
else -> Either.Right(Exception(""))
}

is correctly infered as Either<Int, Exception>