2

Collection<T> is a wrapper around an IList<T>. The list may be attached in constructor. There is no other method provided, as far as I know.

Although ObservableCollection<T> is derived from Collection<T>, you cannot attach an IList<T>. An instance may be constructed from a List<T>, not from IList<T>, and the list is copied.

The public source code seems to confirm the above.

  1. Is this inconsistency a bug?
  2. How do I attach my own IList<T> implementation to an ObservableCollection<T>? The solution must work with the standard ObservableCollection<T>.

I am new to c#. Thank you.

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
CFlat
  • 61
  • 5
  • 3
    Lets say you where allowed to attach a list and if someone adds an item to this original list how can the `ObservableCollection` wrapper ever know about this addition and correctly notify the subscribers of `OnCollectionChanged`? –  Feb 07 '20 at 09:51
  • `Collection` is a handy base class for implementing your own collections. It is not specifically a class for wrapping a list. `ObservableCollection` uses it for convenience, but doesn't keep the "wraps a list" bit. That's OK -- it's allowed to do that (it's not a bug). Indeed, as @Knoop pointed out, how would wrapping a list even work here? – canton7 Feb 07 '20 at 10:05
  • @Knoop Yes, if you keep a reference to the attached list, which is not my case. – CFlat Feb 07 '20 at 10:05
  • `ObservableCollection` can accept `IEnumerable`, which is inherited by `IList` – Pavel Anikhouski Feb 07 '20 at 10:07
  • @PavelAnikhouski You're not wrong, but if you re-read the question you'll see that it's about *wrapping* an existing list, not just copying the elements out of it – canton7 Feb 07 '20 at 10:09
  • @CSharpDummy the collection does not know whether you keep a reference to the attached list or not, so it can never make decisions on that –  Feb 07 '20 at 10:10
  • @PavelAnikhouski Sadly, no. I have my own load-on-demand `IList` implementation which must be used as the underlying container. – CFlat Feb 07 '20 at 10:12

1 Answers1

2

This definately doesn't seem like a bug and I don't know why it would be an inconsistency either.

It's the functionality of an ObservableCollection that prevents this. The functionality guarantees that you can be notify of any changes to the ObservableCollection. To be able to do this it needs full control changes to the underlying data structure that holds its entries.

If it would just "attach" and existing list, there is no handle for the ObservableCollection to be notified of changes. Lets imagine the following scenario:

IList<string> someStringList = new List<string>
{
    "Entry1",
    "Entry2",
    "Entry3"
};

var observableCollection = new ObservableCollection<string>(someStringList);

observableCollection.CollectionChanged += (sender, eventArgs) => Console.WriteLine("Something changed!");

someStringList.Add("This addition cannot be seen by the ObservableCollection!");

Which is consistent, the ObservableCollection has created a copy, so if we look into it it will not contain the "This addition cannot be seen by the ObservableCollection!" entry.

Now if what you wanted would work (so the ObservableCollection would have to original list "attached" instead of copied), we would have something weird. the CollectionChanged event would not have been fired (the addition did not go through the addition of the ObservableCollection) however if you would inspect the observableCollection it would contain the added entry (since it was added to the "attached" list), which would make the whole thing inconsistent.

At least that's my opinion on why this was probably a design choice instead of a bug.

Hope this helps!