Static imports in Java are not “bad”. Static mutab...
# announcements
n
Static imports in Java are not “bad”. Static mutable state can cause problems. Kotlin helps one avoid mutable state, with an emphasis on immutable data and pure functions.
☝️ 1
👍 2
a
I heard stateful static functions are bad. What if the state is stored in an object? i.e.,
Copy code
object Test {
  val list = arrayListOf("a","b","c")
}

fun testerSomething() = Test.list.joinToString()
having the function out of the object is esp nice for extension functions
n
The state in that example is still global.
But yes, global mutable state is often problematic
But Kotlin’s extension functions do not, by themselves, give you mutable state.
a
so it would be bad to have
fun testerAdd() = Test.list.add("something")
i.e., for some type of manager class
n
Yes. In that case, the Test object is a mutable singleton.
That doesn’t encapsulate it’s (global) mutable state
My point is: it’s not the testerAdd function that’s the problem, it’s the Test object.
a
oh I see because list should be private if it is in a class/object
n
I’d say that Test should be immutable.
a
well this would be for a manager class where I would have
fun add(stored: Something)
fun update(stored: Something)
fun remove(stored: Something)
fun get(id: String): Something?
so it would need to be mutable
n
Then I’d advise against making it a global singleton.
a
instead make the storage map private and have all those functions as part of the object?
n
Don’t make it an object declaration
a
oh so the map would not be in a class
(or an object)
n
I mean… don’t make it an object declaration. Define a class. Pass references to instances of that class around. That way, you can control the how the mutability affects different parts of the system explicitly.
a
ok thanks