NotifyCollectionChangedAction: object instance on removal?

Question

I am currently implementing the INotifyCollectionChanged interface for a collection with generally quite critical and short-lived items. All of those items implement IDispose, which can be called immediatly before the removal from the collection. I do not have any control about the destruction order, I will just have to take it as it comes.

My trouble is now, how to propagate the "Remove" actions. The NotifyCollectionChangedAction constructor does provide a variant with only the action specified, but I do have an index of the removed item. Sadly there is no overload taking only an index.

So I guess I could:

• Only pass the "Remove" action
• Pass the remove action along with a "null" object and an index
• Pass the remove action along with a disposed object and an index

Which of those would you prefer? I am a little afraid of implementing such a "core" interface wrong and possibly cause not obviously related bugs ...

I couldn't find any guidelines what happens with the items that are in the "change" lists, are there any available?

Sidenote: The collection will not be immediatly bound to WPF, if thats important.

Answer 1

Basically you are borked.

• Destruction of objects before the removal is a violation of how the interface should work. Point. You can not control it - then you can not implemtn NotifyCollectionChangedAction properly.

• You have to pass the index and the removed object.

Answer 2

From what I can see in MSDN, the only appropriate sets of data for remove are the overload taking the instance, and the overload taking instance and index. You could try the latter passing just the index; it might work... but given the existence of the first overload, I'm not hopeful. If you don't give it the object, downstream code may have no way of knowing which item changed. So I think you're going to have to pass the object. This shouldn't generally cause issues, as most code is simply going to use it for reference check; the object is still there (it hasn't been collected) - it has just been disposed, where "just" is used... subjectively (as this could still cause issues).

Another option, of course, is to wrap the object in a facade. Then it doesn't matter if the actual object is disposed, set to null and/or garbage-collected; the facade is still there (but it should be coded to handle the object being unavailable).

As a final option; do you have to use their collection? Could you not just wrap that collection, so that you choose when to tell it about these things? THen you retain complete control over lifetimes...