Is K/N considered stable? If/when the new memory m...
# kotlin-native
e
Is K/N considered stable? If/when the new memory model is released, will I have to rewrite large portions of my code?
a
h
It is in beta though...
k
Depends what you mean by "stable". Some things will change, for sure, but the api itself isn't going to radically change. The memory model is changing, but unless you're writing concurrency management code, you shouldn't need to worry about that too much, Not everybody will agree with that statement, but the memory model will get less restrictive, not "differently restrictive", so your more strict code should still run.
1
👍 1
2
e
I'm not that well versed in how things work in K/N but would the requirement for explicitly freezing objects, etc... change?
k
Yes, the need to freeze will likely go away. I don't believe the design of the new model is complete, but as I understand it, freezing would be possible but optional. However, if you're using concurrency libraries (coroutines, etc), you generally don't need to freeze your objects explicitly. When you data crosses threads, the library will freeze it in the process.
So, in our production app code, we don't call
freeze()
very often, basically.
👍🏽 2
We're in the process of building a new app and I just did a global search for freeze calls. There are none. The client code generally doesn't need to do that. We do call `ensureNeverFrozen`on view model objects, but that's just me being paranoid.
I would expect this app would run unmodified in the new model, but we could remove Stately and
ensureNeverFrozen
if we wanted to. That's all the changes it would need.
e
That's good to hear. I've been nervous about using it for anything serious because of that, but now I now what I'll be doing work my new years vacation 🥳
👍 1
k
Will new memory model let me remove
AtomicReference
calls from the app? I mean instead of doing this:
Copy code
class Class {
    private val list: IsoMutableList<String> = IsoMutableList()
    private val variable: AtomicReference<String> = AtomicReference("")
}
do this:
Copy code
class Class {
    private val list: MutableList<String> = mutableListOf()
    private var variable: String = ""
}
If so then I can’t wait the new memory model 🙂 (The pattern with Stately types is not something very bad for me to be honest, but if we could avoid it it would make code a little bit more clear)
k
I don't know exactly how the new memory model will work. It might be like the JVM, or something in between. In any case, if you are accessing
Class
from possibly more than one thread, the second example is very risky. You'll need to synchronize that data somehow. They're not thread safe (on the JVM).