Hey guys! Could I get your opinion on a class I've...

# announcements

[Benoît]

Hey guys! Could I get your opinion on a class I've made in order to add backing fields on extension variable ? Don't pay attention to the bad example I use with the theming stuff, I know there's much better ways to achieve theming in Android. I'm more interested on what you think of this as a solution (Kotlin-wise) in order to have backing fields on classes without having to extend them
https://medium.com/@thorebenoit/kotlin-extension-variables-with-backing-field-b430fc6d23e4

[hudsonb]

I think you'd need an identity hash map (a map that compares its keys using ===)

[Dico]

If WeakReference doesn't implement equals/hashCode, you should be able to extend it to do that, which should allow you to actually take advantage of the hash table performance.

[Dico]

You should also run your coroutine in the IO scope, because of the blocking nature. Finally, it should not prevent the map itself from being garbage collected.

[cbruegg]

This doesn't look very efficient. With removeWhen, I believe you're iterating over all entries of the map. The same applies to your getRef method. Also even though you're using a ConcurrentHashMap, I'm not entirely sure whether this is thread-safe.

[hudsonb]

Also there was some discussion about creating a librayr to support this in #C0B9K7EP2 earlier this week. Forget who was asking about it but Im sure they'd be interested in reading this.

[hudsonb]

@joseph_ivie

[Benoît]

@cbruegg Indeed there's a few issues in terms of performance, but I've done some load testing and it seemed to be alright, of course it could be improved. What would you suggest ?

[Benoît]

@Dico Thanks for this !

[Benoît]

Also @cbruegg I tried and it's trade safe 😉 I mean I think it is because when using simple map I was getting ConcurrentModificationException and now I don't

[Dico]

That doesn't mean its threadsafe. A concurrent map iterator doesn't guarantee that by the end of the iteration another thread hasn't inserted the same reference (which would be a duplicate if eq/hashcode isn't implemented correctly)

[Benoît]

Is there any thread safe map then ?

[cbruegg]

The map is safe, but the way you're using it might not be

[cbruegg]

You'll need to use a mutex per map to really make it safe.

[Benoît]

Ok that makes sense now. Thanks guys !

[cbruegg]

Which unfortunately again comes with a slight performance penalty

[joseph_ivie]

Nice! This is better than the naive approach of using WeakHashMap, which doesn't remove its values when the keys get GC'd. Also, be warned: if a value has a reference to its key, it won't be released.

[Benoît]

Well it's never gonna perform as well as extending the class, but in a lot of scenarios it doesn't matter. I made this to be used in light business logic but I wouldn't use it in a draw() loop

[Benoît]

@joseph_ivie Thanks !
If a key as a reference to its value but the key itself isn't referenced anywhere else, it doesn't have a path to GC root so why couldn't be GCed ?

[joseph_ivie]

It would be. I'm saying if the value has a reference back to the key - you're safe in most circumstances. Say, though, you stored a lambda in it that had a reference back to its key. It wouldn't ever GC the key unless the value was explicitly removed. Unfortunately there is no way in the JVM to even make that use case work, so you have it as good as it gets AFAIK.