IMBObject not NSDictionary safe
Daniel Jalkut
I noticed in IMBObjectsPromise.m at the point where the object is set on the dictionary, the comment says:
"Drop down to CF to avoid copying keys"
I think this is key to the problem I'm seeing on Mountain Lion. A friend suggested probably what is happening on Mountain Lion is it's copying the key if it knows that the dictionary it's operating on is in fact an NSDictionary.
IMBObject doesn't implement the required -hash and -isEqual: methods that would allow it to be used reliably as a NSDictionary key.
Because implementing proper hashing and comparison methods for IMBObject might be non-trivial, I would recommend that we switch to a different caching mechanism that doesn't require using the IMBObject itself as a dictionary key:
1. We could just use [NSValue valueWithPointer:theObject]. This would have the effect of linking up precise instances of IMBObject with the cached URL. The downside is it has to allocate a new NSValue every time it adds to the dictionary, and the underlying IMBObject is not retained for the lifetime of the cache.
2. We could use a custom CFDictionary with our own retain, etc., callbacks to ensure the behavior we want. This would essentially be the same as solution 1. but also gives us the power to retain the underlying IMBObject as it does with the current solution.
Any thoughts on what the best approach would be? One of the above, or something else? My bias is towards retaining the object so I guess I'm leaning towards a custom CFDictionary, or else a bogus separate array that just serves the purpose of retaining while we have an NSValue of the object's pointer in our dictionary.
I'll be happy to implement the fix when we agree to something.
Daniel
Mike Abdullah
Sent from my iPad
NSMapTable makes the most sense for this sort of thing I would say.
As the guilty author of this code, what exactly are you testing?
- which os was the code compiled on?
- what was the SDK?
- what was the deployment target?