Hello, what is the difference between ```private ...
# announcements
d
Hello, what is the difference between
Copy code
private val _state = MutableStateFlow<Foo>(Foo())
val state = StateFlow<Foo> get() = _state
and
Copy code
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?
👍 1
z
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.
🙌 1
s
Yeah…. Didn’t understand it either why
get() =
was used and not plain `=`…
d
Oh! I didn't think of the generated code
a
so which one is better?
d
To clarify, neither the val nor the getter are necessary to prevent external users from mutating the contents of
state
☝️ 1
s
val state: StateFlow<Foo> = _state
is a bit more performant… the
get()=
is not needed, in my opinion
z
Why do you think that’s more performant?
s
Why do
get()=
if
=
works as well? A plain field assignment seems simpler to me
z
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).
s
?? I thought it was
Copy code
private val _state = MutableStateFlow<Foo>(Foo())
val state: StateFlow<Foo> get() = _state
vs
Copy code
private val _state = MutableStateFlow<Foo>(Foo())
val state: StateFlow<Foo> = _state
and the 2nd one seems sufficient… why the
get()
?
z
Copy code
// With get() = 
private val _state: String 
fun getState(): String = _state
vs
Copy code
// Without get() =
private val _state: String
private val $_state: String = _state
fun getState(): String = $_state
without the getter, you’re creating an extra private backing field.
s
Ah yes, I see. The
get()=
won’t create yet another backing field.
Hm…. that is nice, although it seems more verbose 🙂
a
one for the other
z
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.
s
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.
👍 1
z
Ultimately, in this case, it almost certainly doesn’t matter, for performance or otherwise.
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.