touchlab
Access AtomicReference as a delegated property
Hey folks, would you be interested in letting AtomicReference be accessed using a delegate? It'll simplify usage by a bit by avoiding the additional get/set calls. I can send a PR if this sounds good to you.
operator fun <T> AtomicReference<T>.getValue(thisObj: Any?, property: KProperty<*>): T = get()
operator fun <T> AtomicReference<T>.setValue(thisObj: Any?, property: KProperty<*>, value: T) = set(value)
Before:
val reference = AtomicReference("foo")
reference.value = "bar" // or set()
println(reference.value) // or get()
After:
var reference by AtomicReference("foo")
reference = "bar"
println(reference)
I'm also thinking that this'll reduce the amount of changes needed to migrate away from AtomicReferences in codebases once kotlin native's new memory model becomes stable.
We did something like this a while ago. I think the reason I was reluctant to include it was because of the memory leak issue. Because of that, you should null out your AtomicReference instances to allow the GC to collect them (which is arguably one of the reasons they're redoing the memory model, at least according to what I've read).
The end result being, if you're using AtomicReference, you should make it nullable and zero those values out. I think that's what kind of stopped us from going down this path in Stately. However, it's useful, so if you want to add it, I think we'll take it!
Because of that, you should null out your AtomicReference instances to allow the GC to collect them
TIL. I had no idea about this. Will have to go through my codebase and check for usages.
if you're using AtomicReference, you should make it nullable and zero those values out. I think that's what kind of stopped us from going down this path in Stately.
Does offering delegate extensions for AtomicReference block people from doing this in any way?
Because of that, you should null out your
AtomicReferenceinstances to allow the GC to collect them (which is arguably one of the reasons they're redoing the memory model, at least according to what I've read).
@kpgalligan is it still the case with the new memory model?
