I always wonder, are `value class` es worth it in ...
# getting-started
u
I always wonder, are
value class
es worth it in world of reactive apps? i.e
Flow<X>
is the base of modern architectures. Somehow I feel like such boxing would produce more garbage than it saves in regular functions. Am I wrong?
y
If you have a
Flow<X>
where X is a value class, it will be boxed. However, if X is some class that has
value
class properties, those won't be, hence it might be very useful for that
u
but it you sum it up, it will be worse, dont you think? since without value class sure I pay the instantiation once, and then its just references, no boxes
y
Yes that's true, although I think improvements to the compiler might fix that. But again, a Flow of a value class will be bad, but having value classes within a complicated structure is definitely good. You could also have a Flow of the raw value that's underlying the value class
u
hm you're right, flow of value is unlikely since it mostly ids for me. which are either arguments or part of a data class btw if I would have a flow of value class, then every operator would create a box?
Copy code
flowOfValue
   .filter { .. }
   .scan { .. }
   .distinctUntilChanged()
second, do you have an idea if this works with Dagger? I have
UserId
a parameter to the graph (
@BindsInstance
) so you can inject "your" userId, without querying the db
btw what about
listOf(FooId("abc"))
is this boxed as well?
k
1. In
filter
it's passed as an argument in the box, so no new instantiation should happen, in
scan
ultimately it depends on what happens inside `scan`; 2. I don't see why it shouldn't work in Dagger, you may have to add qualifier annotation to help dagger distinguish it from raw backing type (
String
or
Long
or whatever you are using); 3. Yes, it will be boxed in any generic (collections, arrays, kotlin function types) or nullable context. You can check whether boxing happens via
show kotlin bytecode
action in IntelijIDEA (or Android Studio), but that requires some knowledge of java bytecode.