Presenting WeakDictionary[TKey, TValue]

Fiberglass flowers / Questions on .NET I don’t expect answers to

Fiberglass flowers / Questions on .NET I don’t expect answers to — Mon, 21 Jan 2008 20:14:37 GMT

PingBack from http://victorsergienko.com/dotnet-cannot-answer/

re: Presenting WeakDictionary[TKey, TValue]

Victor Sergienko — Wed, 13 Feb 2008 19:01:51 GMT

Is it OK that ContainsKey() returns true for collected objects?

I updated ContainsKey() this way:

public override bool ContainsKey(TKey key)

{

// return this.dictionary.ContainsKey(key);

if (!this.dictionary.ContainsKey(key)) return false;

WeakReference<TValue> weakValue;

return (this.dictionary.TryGetValue(key, out weakValue));

}

re: Presenting WeakDictionary[TKey, TValue]

Dan — Mon, 10 Mar 2008 12:20:39 GMT

Not sure what the use would be, having it use WeakReference for both key and value means you have to keep track of both key and value elsewhere, so why would I bother with using this class then?

The use I've had (in Java) for a WeakDictionary was as a cheap cache, when I drop the key it will automatically clear out the value, but as long as I hold on to the key its likely the value will be kept.

I'd also like to question why you feel the need to use internal on the helper classes? If they are so specific that they only have a use for your WeakDictionary class then they should be private under the WeakDictionary, and if you want to be able to use them in more places then public is a terrific way of making sure they are useable where they are needed.

re: Presenting WeakDictionary[TKey, TValue]

Logan Murray — Wed, 02 Apr 2008 20:35:09 GMT

Wow this looks a quite impressive bit of engineering.

I just have a couple comments:

First of all, (I only skimmed the code) you mention that both the key and the value are weak references. This means that the value must also be referenced elsewhere for it to stay alive... you can't just add a new reference to the dictionary. I assume this is by design. For my purposes, however, I need a dictionary that only has weak keys (not values) because I use the dictionary primarily as a datastore. My point in mentioning this is you might be clear on that point because it's rather important to the use of this in a particular design.

Secondly, is not:

"new WeakReference( someObject ) == new WeakReference( someObject )" true?

Why the need for such a complex weak key comparer? Or is this specifically so you can compare weak references to strong references and live ones to dead ones and so forth (though when you think about it you can't really have a live reference and a dead reference pointing to the same object can you? I guess that's why you always return false in this instance).

That said, good work. It's nice to see some advanced .NET coding that really pushes the limits of the framework. ;)

Caliburn Alpha fuer WPF und Silverlight

Caliburn Alpha fuer WPF und Silverlight — Mon, 13 Oct 2008 07:54:17 GMT

PingBack from http://www.silverlight-travel.com/blog/2008/10/13/caliburn-alpha-fuer-wpf-und-silverlight/

re: Presenting WeakDictionary[TKey, TValue]

Andy Kutruff — Fri, 27 Feb 2009 17:08:53 GMT

Amazing work. Just as an FYI, I'm adding this to Continuous LINQ for managing our weak event cache.

High Performance Property Changed Weak Event Notifications for C# « Andy Kutruff

Sat, 07 Mar 2009 00:58:08 GMT

PingBack from http://kutruff.wordpress.com/2009/03/06/high-performance-property-changed-weak-event-notifications-for-c/

Nick Guerrera s blog Presenting WeakDictionary TKey TValue | pool toys

Nick Guerrera s blog Presenting WeakDictionary TKey TValue | pool toys — Thu, 18 Jun 2009 11:45:32 GMT

PingBack from http://pooltoysite.info/story.php?id=3389

re: Presenting WeakDictionary[TKey, TValue]

chha — Thu, 17 Sep 2009 11:12:23 GMT

Thanks for the code, is exactly what I was already looking for many times. I removed the constraints

where TKey : class

where TValue : class

as I often also reference native objects like Int32 etc. although it needs somewhere double-casting in C# (in VB it would need only a single cast, but when I was looking at the effort to translate the "yield" statement, I decided to stay with C# this time...)

Best regards

chha