How do you usually name your property in a `value ...

# getting-started

[ribesg]

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

[Marko Novakovic]

in Compose when am defining routes as value class I name property route.
for example:

@JvmInline
value class Route(val route: String) {
    companion object {
        val Main = Route("main")
        val Dialog = Route("dialog")
    }
}

[Joffrey]

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.

[Marko Novakovic]

just use the name that describes what you need

[Joffrey]

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.

[ribesg]

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

[ribesg]

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

[Joffrey]

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.

[ribesg]

Realized that real quick 😄

eventId.id

[Michael de Kaste]

can someone give me a proper usecase for the value class? without multiple values I can't think of one. thanks! 🙂

[Joffrey]

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

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.

[Michael de Kaste]

I see, very helpful, thanks!

[gildor]

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

[ribesg]

@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 😛

[gildor]

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 !! 😄

[ribesg]

That’s one way to see it, but I just slightly prefer id.value, still don’t like it, so it works anyway 🙃

[Daniel]

UserId(val rawId: String)

[Daniel]

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