Bit of a rant sorry, but am getting a bit fed up with TDictionary. Why is it there is a TryGetValue() function but no TryGetKey() function. I often have a need to find a Key based on the Value and it just doesn't exist. Yes, yes I know I could make my own, but why should I have to C# and Java already have this feature
Because there can be multiple keys for one value? There is no TryGetKey in Dictionary in .Net, period. What you are asking for is nonsense for Dictionary - I guess what you have in mind is a BidiDictionary as that has a 1 to 1 relation between key and value.
ReplyDeleteStefan Glienke I guess so, never thought about that scenario. It makes sense why it's not there now. I do want a a TDictionary where there is a 1:1 relationship between Key and Value. So I guess now I'm thinking about it a bit deeper it is a special case and I'll have to write my own .... Maybe next time I'll think before I rant ( ha ha ). Thanks ...
ReplyDeleteMost efficient may be to maintain two dicts in parallel. The second one containing the inverse relationship.
ReplyDeleteDavid Heffernan Which is what BidiDictionary in Spring4D does :)
ReplyDeleteStefan Glienke I'm not familiar with Spring and it's collections. One day ........
ReplyDeleteThere is a ContainsKey() function. What would you pass to TryGetKey anyway?
ReplyDeleteAllen Bauer The value?
ReplyDeleteStefan Glienke Then which Key would it return? The first one found?
ReplyDeleteI see you've already explained that there isn't a 1:1 relationship between keys and values (ie. the same value can live with different keys). That's why I was wondering at the usefulness of a TryGetKey(). Guaranteeing as 1:1 relationship would clearly complicate the data structures. I presume you understand this, since there is such a class in Spring4D.
Allen Bauer Yes, but for what I need it for there WILL be a 1:1 relationship and I think I would have to write my own class descended from a TDictionary and I would have to make sure no Key or Value was duplicated. That way it would work as I need it to work.
ReplyDeleteTony Danby You do, of course, realize that baking that functionality into TDictionary<> would have made it much more complicated and very likely unsuitable for most other applications? I assure you even if it were an optional feature, that there would be far more "rants" about how slow, big, and bloated the TDictionary<> is and that they don't need all that extra fluff to ensure a 1:1 relationship (more so than they rant already, cough... Stefan Glienke... cough ;-).
ReplyDeleteAs has been stated here, there are specific reasons why that specific functionality doesn't exist. If it were intrinsic to the basic operational algorithms of a Dictionary, then it would have been there.
Oh, and that's the beauty of OOP... you are free to inherit and change existing classes.
Allen Bauer Yep I totally realise why. I realised after the first discussion in this post, but I'd only used TDictionary once before and never really realised what it's intended purpose was, but as I have already mentioned I will be making my own special descended class to meet my needs ....
ReplyDeleteTony Danby I think you'd be better off *not* inheriting, but rather use delegation. That is, make a class (or better, an interface) that does not inherit from TDictionary and exposes the methods you need, and then implement it by keeping an internal TDictionary.
ReplyDeleteYour class is not a traditional dictionary, and thus it's best that it does not pretend it is (by inheriting from TDictionary).
Asbjørn Heid Or better still I make my own class descended from say something like TObject and use a much simpler list, such as TList or TObjectList and achieve what needs to be done that way ... It will be much simpler like that ... I can still get the generics bit in there with I assume .... I'll look into it .... but simple is better ALWAYS .....
ReplyDeleteTony Danby Sure if you don't need the performance from a TDictionary, by all means keep it simple. By delegation you're free to later change the implementation anyway.
ReplyDelete