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

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.

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")
    }
}

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.

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

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.

Realized that real quick 😄

eventId.id

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

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.

I see, very helpful, thanks!

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

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

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

!!

😄

That’s one way to see it, but I just slightly prefer

id.value

, still don’t like it, so it works anyway 🙃