Is there any drawbacks for using `value` class As ...
# kotlin-native
a
Is there any drawbacks for using
value
class As per my understanding it's helpful to make code more readable as many times using type as
Int, String
doesn't explain much about the context so wrapping the types in value class makes it more readable Also should we prefer typealias for these cases or value class is fine
c
Type aliases are just aliases: they do nothing. They're nice when you have a really long time that you use often, for example:
Copy code
typealias EitherFlow<E, T> = Flow<Either<E, T>>
Here, an
EitherFlow<…>
and a
Flow<Either<…>>
are the same thing. When one appears in the code, it's the same as if you wrote the other. Value classes create a new type, that isn't the same as the wrapped value.
Copy code
value class Password(val value: String) {

    // you can use the constructor to refuse invalid values
    init {
        require(value.length > 8) { "Password too short" }
    }

    // you can override how it is displayed (to ensure passwords don't appear in log files)
    override fun toString() = "[***]"
}
Here, a
String
and a
Password
aren't the same thing. You cannot assign a string to a password:
Copy code
val a = "test"
val b: Password = a // doesn't compile
but you can ask the class to convert itself (and it may refuse by throwing an exception):
Copy code
val a = "test"
val b: Password = Password(a) // ok, but may fail
Summary: • use type aliases when you're giving a new name to an existing type, which makes no difference to the type itself or how it's used • use value classes when you want to add things to an existing type to make it into something different (also, this question should have been in #getting-started, not in #kotlin-native)
e
How are value classes treated in native? Are they optimized like in the JVM?
c
I'm not an expert, but I think I remember people saying so, yes. If it's not the case yet, it's definitely planned for the future. AFAIK, the Kotlin team had a prototype which could inline multi-field value classes on JS and Native, but they're not developing it further until Valhalla arrives
✔️ 1
e
Damn, that would be a dream. I'm not using value classes right now because of the additional wrapping in non-JVM platforms like JS.
c
Value classes are inlined on JS already
Look at the generated JS, there is no Password class, it's all just functions that take values as parameter
e
Oh cool! I was missing this one. Well good news
Ahh now I recall why I wasn't using them. Can't be JsExport-ed. I was confusing the two topics.
c
Ah, well, can't do anything about that.
sad panda 1
I mean, JS can only export symbols… by nature, value classes are not symbols…
r
A potential downside of inline classes is interop. For example, if you're calling into Kotlin/Native from Swift, it will just see the inner type and you lose the semantics of the class. So you may want to avoid inline classes at the language boundary. (I would guess that this is also the reason they can't be marked for JsExport)
✔️ 1
c
Yes, they can't be exported because the only thing you could realistically export is the underlying variable. However, value classes have constructors, and there is no way to force someone writing in another language to call the constructor before passing the value. I guess defensively calling the constructor on all function calls (like how Kotlin checks for null parameters for all public functions) would maybe be a possibility? But of course, that has performance implications, and maybe semantic implications as well