Would extension fields be feasible? As in actual ...
# language-proposals
j
Would extension fields be feasible? As in actual storage and retrieval of a value? On the JVM it could use some form of WeakHashMap backing it. Not the default implementation, as it won't clean up after itself properly, but maybe something using PhantomReference. For JS it could actually just use a property I dunno about Native. It could be useful in cases where you want to "tag" an object with some data, but only want that data around as long as the object.
👍 1
x
I feel like this is needed for my desire for complete trait support
h
It'd be a nice feature. We've gotten into the habit of including a property map in a bunch of classes to make such a thing possible.
Obviously that only helps with classes you control.
j
I think I could make library for this, actually, if I had some way of handling native. The one sketchy thing is the JVM implementation - if the value had a strong reference to the key, then it wouldn't release properly. I don't know if there is a way around it.
k
WeakHashMap
has weak keys, isn't that exactly what you want?
h
It's not enough, it has to be an identity hashmap
k
There's the
equals
problem of course.
@hudsonb What do you mean?
h
HashMap
compares keys using
equals
, an identity hashmap compares them by reference. To build a library on the JVM which allowed for extension fields, you'd probably need a static identity hashmap.
A weak identity hashmap in particular
k
Yeah okay, so we're talking about the same thing simple smile
I'd never heard of the term "identity hashmap" before.
That's not enough though, you need a weak identity hashamp
k
And it implements
Map
, great 😕
h
An impl of a weak identity hashmap + delegated properties + extension properties would make an interesting JVM lib
j
I’ve used the pattern a bunch, before I realized
WeakHashMap
only cleans itself up when you ask for its size or it needs to expand. That’s why you’d need to use PhantomReference.
k
Are you sure about that? The javadoc seems to imply keys get removed when the references say so.
j
Yeah, I’m sure. Testing says it doesn’t work that way. Maybe the JVM works that way, but not Android. It lead to a huge bug yesterday that we went crazy over trying to figure out.
expungeStaleEntries
(a private function in
WeakHashMap
) is called only under a couple of scenarios, which only happen sometimes.
Clarification: keys get removed, but the values do not. That’s the problem.
x
a weak hashmap shouldn’t prevent the value from being gc-ed, its references don’t count (my understanding)
e
It does not look like you need a language-feature for that. You can go ahead and implement it via extension delegate properties today in your own library/project.
3
k
That
removeWhen
call is bad 😞
b
What do you suggest ?
k
Write/find a
WeakIdentityMap
and use that.
b
thanks
k
Also, make sure the whole thing is threadsafe. You already did that I see simple smile
b
Apparently it isn't I need to implement a mutex as well but thank you for spotting it