XML does not work well as Dictionary keys. For your scenario, why couldn't
use just compare parent() nodes?
Thanks for the reply. You are right. I could have compared parent() for the scenario I described. However I need to accomplish something else at the same time which was why I used Dictionary. I got my program to work in another way. Nontheless the original question regarding the Dictionary behavior remains. My current observation is that XML node itself works fine as Dictionary key. It's probably the untype nature of parent() method that caused the problem. Dictionary documentation isn't very clear on this (it only stress on strict equality which is satisfied in my snippet). Can anyone confirm?
The Flex SDK team does not use XML as Dictionary keys. They store and
return a value, but they do not compare to another XML fetch, even thought
=== does. I don't think it has anything to do with the return value being
untyped since the what is returned is, in fact, strongly typed.
Is it the recommendation from Flex SDK team not to use XML as Dictionary key? Apparently XML as key does cause problem like this one. But to me it's more like a workaround about a flaw in the system. Either the Dictionary or the XML has design flaw. If we can't reliably use Object (which XML is) as key, why bother introducing Dictionary? We can all go back and use String backed associate array.
Yes, that is the recommendation. It is a workaround. I'm pretty sure there
is already a bug on it.
Dictionary works great for all objects except XML and String. I'm very glad
we have it.
Egads! Dictionary doesn't work for String keys? Or do you just mean they're overkill for String keys, as plain Object will work fine?
A weak key dictionary with Strings as the key is asking for trouble because
Strings are interned. Don't use String as weak keys and if then you might
as well use Object instead.