-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Access AtomicReference as a delegated property #69
Comments
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! |
TIL. I had no idea about this. Will have to go through my codebase and check for usages.
Does offering delegate extensions for |
Bumping this again for visibility |
@kpgalligan is it still the case with the new memory model? |
Hey folks, would you be interested in letting
AtomicReference
be accessed using a delegate? It'll simplify usage by a bit by avoiding the additionalget
/set
calls. I can send a PR if this sounds good to you.Before:
After:
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.
The text was updated successfully, but these errors were encountered: