https://kotlinlang.org logo
Title
a

Andrew Gazelka

11/21/2018, 3:31 PM
I am looking at docs and see this. Why wouldn't
isEmpty
be a function? Also wouldn't the value stored in
isEmpty
never be referenced?
o

orangy

11/21/2018, 3:32 PM
In this case property doesn’t have a backing field.
a

Andrew Gazelka

11/21/2018, 3:38 PM
aight thanks
s

sindrenm

11/21/2018, 3:38 PM
What's the recommended pattern here, btw? Myself, when I see that something is declared a
val
, and I know that the type that the
val
is referencing is deeply immutable (like a
Boolean
), I want to believe that what I receive from accessing the property is the same every time. Of course, with the case of custom getters like this, it's not necessarily the same every time, like if this is a property defined in a mutable list. Essentially, what I'm wondering if it's “OK” to write code like this, where the deeply immutable “contents” of a
val
can change from each invocation of the getter.
a

Andrew Gazelka

11/21/2018, 3:39 PM
well, it is in official docs, so I would guess so
same with how you would define a lambda as
val
even though a lambda can change outputs
s

sindrenm

11/21/2018, 3:40 PM
Sure, but a “pure lambda” wouldn't have that same problem, right?
a

Andrew Gazelka

11/21/2018, 3:40 PM
we aren't assigning different getter logic, so it doesn't make sense to have it
var
(imo)
s

sindrenm

11/21/2018, 3:41 PM
No, I'm thinking that in cases like this it might make “more sense” to have a function
isEmpty(): Boolean
instead, perhaps?
a

Andrew Gazelka

11/21/2018, 3:41 PM
oh, I see
yeah, I'd agree too probably... most things could be computed in a field getter
even when it makes more sense to be in a func
s

sindrenm

11/21/2018, 3:43 PM
Of course,
val
does not by any means suggest that the thing referenced is immutable, but that's another topic. One could, for instance, have a
val names: MutableList<String>
.