Hello, what is the difference between ```private val _state = MutableStateFlow<Foo>(Foo()) va...

# announcements

[Daniel]

Hello, what is the difference between

private val _state = MutableStateFlow<Foo>(Foo())
val state = StateFlow<Foo> get() = _state

and

private val _state = MutableStateFlow<Foo>(Foo())
val state = StateFlow<Foo> = _state

?

Jetbrains and Google use the first form in their documentation, but isn't a val read-only regardless of whether it is specified as only having a getter or not?

[Zach Klippenstein (he/him) [MOD]]

The second form creates a separate backing field that stores the same instance as _state, as well as a getter for that backing field. The first form only creates a getter that wraps the _state field.

[streetsofboston]

Yeah…. Didn’t understand it either why get() = was used and not plain `=`…

[Daniel]

Oh! I didn't think of the generated code

[Alejandro Rios]

so which one is better?

[Daniel]

To clarify, neither the val nor the getter are necessary to prevent external users from mutating the contents of state

[streetsofboston]

val state: StateFlow<Foo> = _state is a bit more performant… the get()= is not needed, in my opinion

[Zach Klippenstein (he/him) [MOD]]

Why do you think that’s more performant?

[streetsofboston]

Why do get()= if = works as well? A plain field assignment seems simpler to me

[Zach Klippenstein (he/him) [MOD]]

It’s really an implementation detail, but the latter requires an extra useless field in your class, which makes your object sizes slightly larger in theory (I’m not sure if this gets optimized out by R8).

[streetsofboston]

??
I thought it was

private val _state = MutableStateFlow<Foo>(Foo())
val state: StateFlow<Foo> get() = _state

vs

private val _state = MutableStateFlow<Foo>(Foo())
val state: StateFlow<Foo> = _state

and the 2nd one seems sufficient… why the get()?

[Zach Klippenstein (he/him) [MOD]]

// With get() = 
private val _state: String 
fun getState(): String = _state

vs

// Without get() =
private val _state: String
private val $_state: String = _state
fun getState(): String = $_state

[Zach Klippenstein (he/him) [MOD]]

without the getter, you’re creating an extra private backing field.

[streetsofboston]

Ah yes, I see. The get()= won’t create yet another backing field.

[streetsofboston]

Hm…. that is nice, although it seems more verbose 🙂

[Alejandro Rios]

one for the other

[Zach Klippenstein (he/him) [MOD]]

In this case, the behavior is the same. If the backing field were mutable, then the two forms would have meaningfully different behavior. So there’s some different intent communicated as well.

[streetsofboston]

Thank god JetBrains is working on a way to have a private facing and public facing type, removing the need for the odd backing field solution.

[Zach Klippenstein (he/him) [MOD]]

Ultimately, in this case, it almost certainly doesn’t matter, for performance or otherwise.

[Zach Klippenstein (he/him) [MOD]]

If you have a million instances of this class, then the fields would probably start to add up, but you’d probably run into other issues long before that.