Mapping from a type to an instance of that type

re: Mapping from a type to an instance of that type

skeet — Sun, 12 Oct 2008 18:18:01 GMT

Pavel: I've had another look at KeyedByTypeCollection, and it does look somewhat like it, yes. It's a shame the docs are so poor. (It's really unclear what it's actually doing to start with.)

Personally I prefer the API of DictionaryByType - it makes it clearer what's going on, IMO, and it doesn't artificially implement the other collection interfaces (which can't really express what's going on cleanly). My class also has an interface close to the Dictionary API, with TryGetValue for example. (I'd have used an indexer instead of Get/Put, but they can't be generic.)

Worth knowing about, though - thanks.

re: Mapping from a type to an instance of that type

Pavel Minaev — Sun, 12 Oct 2008 17:06:35 GMT

TItem that you give is the common base type for all types in the collection. Naturally, you can just use Object if you don't want any restrictions whatsoever (which is rare - more often, when you use such a thing as e.g. a factory class registry, you have some common base interface you want to enforce). But otherwise it's precisely the same - the key for the item is its type as returned by GetType(), and there can only be one item of a given type. E.g.:

using System;

using System.Collections.Generic;

static class Program

{

static void Main()

{

var d = new KeyedByTypeCollection<object>();

d.Add(123);

d.Add(123.456);

d.Add('x');

d.Add("foo");

Console.WriteLine(d.Find<int>());

Console.WriteLine(d.Find<double>());

Console.WriteLine(d.Find<char>());

Console.WriteLine(d.Find<string>());

d.Remove<int>();

d.Remove<double>();

d.Remove<string>();

d.Add('y'); // throws

}

re: Mapping from a type to an instance of that type

skeet — Sun, 12 Oct 2008 15:38:05 GMT

Pavel: I can't say I've used KeyedByTypeCollection before, but it looks like the values are all the same type (TItem) as opposed to the value for a particular key being an instance of that key (type).

re: Mapping from a type to an instance of that type

Pavel Minav — Sun, 12 Oct 2008 14:44:22 GMT

Isn't the stock KeyedByTypeCollection<T> class designed to solve precisely this problem?

re: Mapping from a type to an instance of that type

skeet — Thu, 09 Oct 2008 22:04:51 GMT

Ben: That limits you to a single type/value mapping. DictionaryByType lets you have as many dictionaries as you want.

re: Mapping from a type to an instance of that type

Ben Voigt [C++ MVP] — Thu, 09 Oct 2008 21:52:38 GMT

Jon,

What advantage does your method have over generic statics?

public static class OneAndOnly

{

private static class Content<T>

{

static bool HasValue;

static T Value;

}

public void Add<T>(T value)

{

if (Content<T>.HasValue)

throw new DuplicateKeyException();

Put(value);

}

public void Put<T>(T value)

{

Content<T>.Value = value;

Content<T>.HasValue = true;

}

public T Get<T>()

{

if (Content<T>.HasValue)

throw new KeyNotFoundException();

return Content<T>.Value;

}

public bool TryGet<T>(out T value)

{

value = Content<T>.Value;

return Content<T>.HasValue;

}

public void Remove<T>()

{

Content<T>.HasValue = false;

}

re: Mapping from a type to an instance of that type

SeeR — Thu, 09 Oct 2008 21:48:59 GMT

That was me the guy who asked that question on stackoverflow an I think I found the solution.

See my blog seermindflow.blogspot.com/.../is-it-possible-to-write-c-application.html

or my answer on stackoverflow

re: Mapping from a type to an instance of that type

Todd — Thu, 09 Oct 2008 17:29:06 GMT

With a traditional dictionary it seems much more clear who is the owner of the lifetime of the objects within the dictionary. In the case of a dictionary that contains the sole reference to IDisposables it is obvious that they all need to be disposed when the dictionary is no longer needed.

It seems like with this dictionary the benefit partially lies in the ability of not knowing what people would put in it.

The main reason why IDisposable came to mind was that the StackOverflow post adds a SqlConnection to the dictionary.

Maybe my real concern is that this type of dictionary is not suitable for IDisposables at all, or at least not database connections. Maybe it would seem more correct if it was an object that created database connections.

re: Mapping from a type to an instance of that type

skeet — Thu, 09 Oct 2008 16:28:43 GMT

Todd: The dictionary shouldn't care about any more than the .NET Dictionary class cares if you add references to IDisposable instances. It's up to the client to clean up.

re: Mapping from a type to an instance of that type

Todd — Thu, 09 Oct 2008 16:14:37 GMT

What do you do when someone decides to store an IDisposable object in this dictionary? Should this dictionary be disposable and dispose of any disposable values when the time is appropriate?

re: Mapping from a type to an instance of that type

skeet — Thu, 09 Oct 2008 12:26:25 GMT

@Clippy: That's certainly one use for it (and the one in the SO question). As it happens, my use was somewhat different, and not service based :)

Clippy Appears!

clippy — Thu, 09 Oct 2008 11:54:47 GMT

"Hi, It looks like you're writing an IOC container!

For service locator functions it might be useful to take a look at using the CommonServiceLocator interface www.codeplex.com/CommonServiceLocator. Not only is this nice and clear, but also will minimise friction if you decide to use an existing IOC container later."

re: Mapping from a type to an instance of that type

James Hart — Thu, 09 Oct 2008 11:25:39 GMT

Agreed, it's a lot of effort to go to just to avoid a cast - though the possibility of avoiding boxing primitives in the dictionary might be a more tempting reason to use it, the weak key cleanup would probably introduce a horrendous overhead in any implementation that was using enough instances of this type to benefit from the savings due to boxing :)

That approach is actually derived from one that came up when trying to come up with a state mechanism for extension methods, where the idea of a weak dictionary makes more sense.

re: Mapping from a type to an instance of that type

skeet — Thu, 09 Oct 2008 09:55:38 GMT

Ooh, interesting. I'd thought of the use of generic statics, but run into the "values per dictionary" issue - which you've neatly sidestepped.

I think I probably prefer the cast to using weak references, but that's a really interesting approach :)

re: Mapping from a type to an instance of that type

James Hart — Thu, 09 Oct 2008 09:37:11 GMT

If you have a weak dictionary implementation (one that uses weak-reference keys and cleans out otherwise unreferenced keys and their associated values), you could try something like this to avoid casts:

public class TypeDictionary

{

private class InnerTypeDictionary<T>

{

static WeakDictionary<TypeDictionary, T> _innerDictionary = new WeakDictionary<TypeDictionary, T>();

public static void Add(TypeDictionary dic, T value)

{

_innerDictionary.Add(dic, value);

}

public static T GetValue(TypeDictionary dic)

{

return _innerDictionary[dic];

}

public void Add<T>(T value)

{

InnerTypeDictionary<T>.Add(this, value);

}

public T GetValue<T>()

{

return InnerTypeDictionary<T>.GetValue(this);

}

Reflective Perspective - Chris Alcock » The Morning Brew #197

Reflective Perspective - Chris Alcock » The Morning Brew #197 — Thu, 09 Oct 2008 07:20:05 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #197

re: Mapping from a type to an instance of that type

Jesper — Wed, 08 Oct 2008 20:59:56 GMT

I'd expect the Dictionary type to track the generic IDictionary interface fairly closely. Fair enough, I suppose, since other interfaces and classes don't necessarily.

re: Mapping from a type to an instance of that type

skeet — Wed, 08 Oct 2008 20:48:18 GMT

@Jesper: Just general principle. I tend to like to use interfaces where I can. It (hopefully) makes it clear to anyone reading the code that I'm not relying on any particular extras supplied by Dictionary.

re: Mapping from a type to an instance of that type

Jesper — Wed, 08 Oct 2008 20:42:44 GMT

Is there a particular reason why you typed a private readonly object that's only ever a Dictionary as the interface it implements?