I am looking at docs and see this. Why wouldn't `i...

# announcements

[Andrew Gazelka]

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?

[orangy]

In this case property doesn’t have a backing field.

[Andrew Gazelka]

aight thanks

[sindrenm]

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.

[Andrew Gazelka]

well, it is in official docs, so I would guess so

[Andrew Gazelka]

same with how you would define a lambda as val

[Andrew Gazelka]

even though a lambda can change outputs

[sindrenm]

Sure, but a “pure lambda” wouldn't have that same problem, right?

[Andrew Gazelka]

we aren't assigning different getter logic, so it doesn't make sense to have it var (imo)

[sindrenm]

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

[Andrew Gazelka]

oh, I see

[Andrew Gazelka]

yeah, I'd agree too probably... most things could be computed in a field getter

[Andrew Gazelka]

even when it makes more sense to be in a func

[sindrenm]

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>.