   Using types as keys in dictionaries
  Hi,only recently I had discussion about "Using types as keys in dictionaries".Long story short: I will always try to avoid using types as keys.Here is why:A dictionary is there to look up things associated with other things.Often the things, others are associated with, are indeed all types, like in this made-up example:Assumed we wan't to store information about what to display on screen for certain items. Also assumed Customer, Product and Adress are types in our software.If so, we could have code like this:Dictionary< Type, DisplayInfo >Customer -> DisplayInfo( "FirstName", "LastName" )Product -> DisplayInfo( "ProductName", "Price" )Adress -> DisplayInfo( "Street", "Zip", "City" )...At a first glance this looks pretty O.K., but it will become a bad pitfall.This lookup information datastructure will become used all over the place. It will become manipulated dynamically, queried, copied, stored to XML files,...Then right before the next milestone, some marketing guy will require us to display manufacturer info with parts of the Products, but not with all of them.Product??? -> DisplayInfo( "ProductName", "Price" )Product??? -> DisplayInfo( "Manufacturer", "ProductName", "Price" )What are we going to do now? REfacture half the product? Invent an artificial type wrapper MProduct? Well yes we can do this, but this was really ugly, and doing things like that leads straight to unmaintainable code.Btw. don't think about adding conditional code to DisplayInfo. It's 3rd party - no way changing it.Well we would have been fine, if we chose a less limited keytype in the first place. E.g. a simple string.Dictionary< String, DisplayInfo >MakeKey( Customer ) -> DisplayInfo( "FirstName", "LastName" )MakeKey( Product ) -> DisplayInfo( "ProductName", "Price" )MakeExtKey( Product ) -> DisplayInfo( "Manufacturer", "ProductName", "Price" )MakeKey( Adress ) -> DisplayInfo( "Street", "Zip", "City" )...Well I know there is much that could be discussed about this example, but the only point I want to make is:"Do not use types as keys".Or in other words:"Do not use keytypes that are limited in any way, because you will get to limits sooner or later."Well, why am I writing this here? My question to you is:Is my argument sufficient to make it a general rule, which, if you stick to, will make your life simpler?Did I miss some important point, that turns "Do not use types as keys" to complete nonsense?Best Jochen   
  I'm not sure I understand your example sufficiently to argue that point, but outside of that I've not seen any good reason not to use a type as the key in a dictionary. It's rare and maybe should be avoided, but not overly problematic.   ;  It seems like the lesson here is "isolate implementation details" rather than "don't use types as keys".   ;  I agree that the problem you have here is less to do with types as keys and more to do with poor design of the system overall. There are plenty of scenarios where you might want to use Type as a key, especially in favor of String. Perhaps yours was not one of those cases, but that doesn't mean you should arrive at such a generalization because of it.   ;Quote:It seems like the lesson here is "isolate implementation details" rather than "don't use types as keys"."isolate implementation details" for sure is a good general rule to follow.So SiCrane, would you agree to: "Using types as keys violates the rule of hiding implementation details?"   ;Quote:So SiCrane, would you agree to: "Using types as keys violates the rule of hiding implementation details?"I certainly wouldn't. It depends on the scenario.   ;  As I interpret it, your statement is "I will always try to avoid using types as keys metaprogramming". Is that the case?(Edit: Can this even be called metaprogramming?) IMO it's efficient to use whatever gets the job done without nasty side effects. "Pragmatic programming" is sadly not code poetry, but does it matter? If this way of using types doesn't resonate with you, come up with an alternative to it and then compare the pros and cons of the different solutions.;  Let me state again that this was a made up example.I personally never use types as keys, for no special reason up to now, but I came across serveral pices of code, where types where used as keys and turned out to be a problem, which to resolve, was more effort, than initially introducing a more flexible key type.It's more like: I made bad experince with type - keys and therefore I avoid them.Quote:There are plenty of scenarios where you might want to use Type as a key, especially in favor of String.I do not use "string keys" per se all over the place. Expecially not if performance matters and containers are large.Atm I can not think of a propper example where I would favor Type over String as a key type for a dictionary. Could you maybe give one?Best JochenEdit: fixed typo   ;Quote:Original post by jochenSo SiCrane, would you agree to: "Using types as keys violates the rule of hiding implementation details?"No, not at all. Using a type as a key is an implementation detail: if you can't change that without problems then you haven't hidden that implementation detail.  And the sentence remains the same if your replace "type" with "string", "int", "UUID", "cow", "donut" or "biopsy sample".   ;Quote:As I interpret it, your statement is "I will always try to avoid using types as keys metaprogramming". Is that the case?Certainly not. But to be honest, I can't see a relation between "metaprogramming" and "using types as keys".Best Jochen   