Dropping Data Structures into the Pit of Success
As part of the work that I am doing for Rhino ServiceBus, I am also creating a few data structures.
No, I haven't gone mad and decided that it is a good idea to write my own linked list, but I have discovered that there are several patterns that I am using that require some potentially tricky coding, so I decided to gather them into a single place so I wouldn't have to do this again.
It is important to note that those are not actually data structures that I am using inside Rhino ServiceBus, rather, those are data structures that I expect users of Rhino ServiceBus to use.
Currently I have LRU Set and thread safe dictionary. Both of which, mind you, are following a completely different approach that the usual approach that you would see in standard collections.
Here is an example of how this can be used:
dic.Write((add,remove) =>
{
add("a", 5);
remove("b");
add("c", 6);
});It also try to provide an interface that is as small as possible, because I don't want to give flexibility here. There are very specific use cases for those data structures.
Comments
Actually, the linked list in .NET is pretty bad, as it doesn't have an O(1) concat operation between two linked lists, because every element in the linked list has a reference to the linked list master object.
LeastRecentlyUsedSet sounds a bit like a reverse WeakHashmap in java?
Internally are you just wrapping the .NET dictionary in thread safe locking, or are you actually implementing your own list?
How does GetEnumerator work for threading scenarios? Does it provide a snapshot of the dictionary?
No, it is just a bucket that can contain up to X items.
This allow you to maintain a fixed list without worrying it about grow too big
Configuratior,
Yes, I return a snapshot
Jason,
Wrapping, yes. No interest in trying to implement them myself
This just about sums up software development: roll your own <whatever.
The state of the .NET framework, available .NET commercial libraries, and Open Source librariesmust be crap for you to do this.
Maybe you can add your stuff to http://www.codeplex.com/PowerCollections?> But then we also have another collection library that ships with NHibernate?
The Madness of Software Development.
I'm not happy about the lambda syntax. While expressions and lambdas allow for richer APIs, they also make them less intuitive and less discoverable. This was also my experience when I first tried to use RhinoMocks 3.5.
Specifically for the above case, perhaps consider:
dic.Write(writer => {
writer.Add("a", 5);
writer.Remove("b");
writer.Add("c", 6);
}
or even using a child object rather than a lambda to record updates (a-la dict.GetWriter()).
This would be slightly better in terms of discoverability, I think.
Avish, you're still using a lambda, I think what you're saying is that you're not comfortable with delegates as objects. It did make me do a double take for a second, but it makes sense to me.
But I do see how having a separate object and calling functions on that object might be a bit more intuitive.
Avish,
That particular syntax actually exposes a bug in the C# compiler, so I am removing that.
Would you mind sharing the threadsafe dictionary?
I'm trying to port (as much as I can) the Castle.DynamicProxy2 to silverlight.
I wanted to replace the Hashtables used with a Dictionary <key,value> but there is a case where it's using a Syncronized hastable...
Any thoughts?