https://kotlinlang.org logo
#getting-started
Title
# getting-started
r

ribesg

11/25/2021, 8:58 AM
How do you usually name your property in a
value class
? I just always name it
value
and I wonder if there is another way that would make more sense
m

Marko Novakovic

11/25/2021, 9:00 AM
in
Compose
when am defining routes as
value class
I name property
route
. for example:
Copy code
@JvmInline
value class Route(val route: String) {
    companion object {
        val Main = Route("main")
        val Dialog = Route("dialog")
    }
}
j

Joffrey

11/25/2021, 9:00 AM
I really depends, I usually use a name that explains what exactly is stored there. For instance, if you were implementing your own
Duration
value class, you could choose to represent the inner value in many ways. For instance, it could be
milliseconds: Long
or
nanoseconds: Double
- and you'd better give a clear name here because
value
would be quite uninformative. Same goes for an
Angle
value class, that could store degrees or radians. Basically any unitless class that needs to use a unit to store a value should specify the unit. That's just one example though.
💯 2
🙏 1
m

Marko Novakovic

11/25/2021, 9:00 AM
just use the name that describes what you need
👍 1
j

Joffrey

11/25/2021, 9:04 AM
There are cases where
value
is ok of course, when there is no more information to bring. For instance,
value class Password(val value: String)
. But even here we could argue that
Password(val clearText: String)
would be nicer.
👍 2
r

ribesg

11/25/2021, 9:05 AM
I’m really using them for id classes right now, to wrap strings and ensure I’m not passing one kind of id to something where I mean another (I have functions which take multiple ids of different kind as parameter). So maybe I should just name them
id
I just felt like I was using
value
everywhere for the wrong reason, like “I know it’s a
value class
so I know I need to call
value
on it to get the actual value”, but you shouldn’t really care that it’s a
value class
when using it I think. Just like if it was a
typealias
, but with type check
j

Joffrey

11/25/2021, 9:09 AM
but you shouldn’t really care that it’s a 
value class
 when using it I think
Exactly. That's precisely why I think it's nice to choose a property name that makes sense when you read it.
password.clearText
is nice,
password.value
is OK (slightly more ambiguous, but I think everyone gets it). But it's always on a case-by-case basis for me:
userId.value
may actually be less weird than
userId.id
when using it, so maybe
value
is not that bad here. Even worse, imagine you have
data class User(val id: UserId)
. I would hate to read
user.id.id
so IMO in this case
user.id.value
is better.
also yes 2
r

ribesg

11/25/2021, 9:14 AM
Realized that real quick 😄
Copy code
eventId.id
😂 1
m

Michael de Kaste

11/25/2021, 2:38 PM
can someone give me a proper usecase for the value class? without multiple values I can't think of one. thanks! 🙂
j

Joffrey

11/25/2021, 2:48 PM
It's useful when you want more type safety, without a runtime overhead. For instance if you manipulate values that have dimensions (like length, weight, time, light intensity, you name it), it may be very useful to use specific classes instead of
Int
or
Long
to avoid messing up what can be combined with what. It also prevents passing a distance to method that expects a duration. This is the type safety benefit. And if you're hardcore you can even define extension functions like
Copy code
operator fun Length.times(other: Length): SurfaceArea

operator fun Speed.times(time: Duration): Distance
operator fun Distance.div(time: Duration): Speed
And you never get lost about the dimensions you're working with. It's really interesting as opposed to using regular primitive types. Another example could be using a
Password
class instead of a
String
to avoid mixing passwords with other sorts of texts. However, wrapping all of those into
data class Password(val value: Int)
might have a non-negligible cost at runtime due to the boxing of primitives into objects. Value classes are a way to tell the compiler that you don't care about the identity of your objects (just equality of the value inside), and thus the compiler can optimize the boxes away in many cases.
👍 3
m

Michael de Kaste

11/25/2021, 2:56 PM
I see, very helpful, thanks!
g

gildor

11/26/2021, 3:13 AM
I would hate to read 
user.id.id
I think it’s a less a problem if you unwrap your value classes only when you need an actual value and most of business logic works with value class itself
r

ribesg

11/26/2021, 9:13 AM
@Michael de Kaste in my case I have a whole bunch of different ids which are (were) all Strings, and sometimes it can get tricky with functions taking multiple different kind of ids as parameters or with contexts where I have different kind of ids in the code in general. By giving a proper type to the ids (which is what using `value class`s did in my case) I discovered multiple occurrences of errors where I was comparing the wrong kind of ids, and this way fixed a few bugs. @gildor true, I almost never unwrap them actually, but when I do,
id.id
still triggers me 😛
g

gildor

11/26/2021, 9:17 AM
So, doesn’t it mean that id.id is actually a good thing?! It makes usage of it be uncomfortable for developer, as intended, like with
!!
😄
r

ribesg

11/26/2021, 9:37 AM
That’s one way to see it, but I just slightly prefer
id.value
, still don’t like it, so it works anyway 🙃
😆 1
1
d

Daniel

11/27/2021, 9:03 PM
UserId(val rawId: String)
👍 1
If you have good boundaries in the code you will only need to call userId.rawId in a low level layer (for example when making a backend request). In all other places you pass the stronlgy typed Id around
2 Views