https://kotlinlang.org logo
Join Slack
Powered by
since enums can't have variables/properties (can t...
# announcements
t
since enums can't have variables/properties (can they?) is seal classes how people generally simulate union types?
s
They can have properties, even variable ones.
t
oh. what's that syntax like? I tired a few things and none of them compiled.
s
Copy code
enum class MyEnum(var value: Int) {
    VALUE_ONE(1),
    VALUE_TWO(2)
}
t
those are static. every VALUE_ONE will have the same value.
yes?
s
Yup, and you can do 
VALUE_ONE.value = 4
I don’t recommend this type of coding, but it is possible 🙂
However enums with constant 
val
properties are fine.
t
I don't think that works.... I'm trying to do a union
s
?
A Union types!
t
there is no union type in kotlin... I don't think. is there?
s
They carry state/data and enums don’t really do that (they are singletons/global)
Not yet (the folks creating the Arrow library are creating Union types for Kotlin using compiler plugins)
There are sum-types in Kotlin
t
yeah, exactly. imagine a DayOfWeek enum. Monday, Tuesday .... but each one has a property that carrys DaysSinceEpoc. I don't want to create a enum for every day since 1970.
right, so back to the question, how do people do unions? I've fudged it w/ a sealed class... is there anything better?
s
Kotlin has only one union-type, the nullable type e.g 
String?
, which is 
String
or 
null
. Best approximation is either-types. E.g
Copy code
sealed class Either<out A, out B> {
    data class Left<out A>(val left: A): Either<A, Nothing>()
    data class Right<out B>(val right: B): Either<Nothing, B>()
}
But the above is a sum-type…. you can use it to approximate union-type behavior
t
I don't need generics. the types only differ by name, not value. but yeah, that's what I did. a sealed class.
n
Sealed class is the closest thing
to answer your question
It's kind of a pain because it's intrusive
s
n
so you can't have things directly in the sealed class, if you don't control them
you have to go through wrappers
but then because of how type erasure works on the JVM, You can't even have a generic wrapper
you have to write a wrapper for each one individually
it's not good
Either proper sum/union types, or the proposal that allows adding interfaces/traits to existing classes, would fix this. And FWIW I hope both of these make it in soon.
☝️ 1
s
Type erasure happens at run-time. Not that worried about that 🙂 But giving the compiler at compile-time the wisdom to be able to handle Union types, that would be great. Can’t wait to see what the Arrow folks have done with that 🙂
n
@streetsofboston that's not what the issue is with type erasure in this context
the issue is that if you try to define a generic wrapper type
actually, i realized, you can't define a generic wrapper type anyway because you can't constrain the generic, so nvm 🙂
C++ developer still getting used to kotlin
s
😀 Yup... It is something you need to get used to. But I don't really miss it. Just remember `List<Int>::class == List<String>::class`; their classes are the same (type erasure), but their types are different (
typeOf(List<Int>) != typeOf(List<String>)
).
t
@Nir yeah.... same issue. go to grab that thing you expect and it's just not there 🙂 old habits...
for what I'm trying to do, I'd be happy of sealed classes could be inline
n
Well, I think even have reified generics wouldn't help in this case
the problem is the constraint system
the only want to constrain things in Kotlin is via inheritance, and inheritance is intrusive
it's a headache sometimes
t
yeah. scala did some stuff with generics and restricting type that's kinda cool.
but it comes w/ scala's type system... which is... complex and causes it's own set of problems.
n
Yeah, I think a mild upgrade over what kotlin has is enough to make me happy
j
Check Arrow Meta for this
Open in Slack
PreviousNext
Powered by