Added Range Manipulation APIs to Collection<T> and ObservableCollection<T>

[SkyeHoefling]

Added Range Manipulation APIs to Collection<T> and ObservableCollection<T>.

Fixes: #10752 - migrated to: dotnet/runtime#18087

Added the following new API that was approved:

    // Adds a range to the end of the collection.
    // Raises CollectionChanged (NotifyCollectionChangedAction.Add)
    public void AddRange(IEnumerable<T> collection) => InsertItemsRange(0, collection);

    // Inserts a range
    // Raises CollectionChanged (NotifyCollectionChangedAction.Add)
    public void InsertRange(int index, IEnumerable<T> collection) => InsertItemsRange(index, collection);

    // Removes a range.
    // Raises CollectionChanged (NotifyCollectionChangedAction.Remove)
    public void RemoveRange(int index, int count) => RemoveItemsRange(index, count);

    // Will allow to replace a range with fewer, equal, or more items.
    // Raises CollectionChanged (NotifyCollectionChangedAction.Replace)
    public void ReplaceRange(int index, int count, IEnumerable<T> collection)
    {
         RemoveItemsRange(index, count);
         InsertItemsRange(index, collection);
    }

    #region virtual methods
    protected virtual void InsertItemsRange(int index, IEnumerable<T> collection);
    protected virtual void RemoveItemsRange(int index, int count);
    #endregion

Added Unit Tests

• Collection<T>
• ObservableCollection<T>

I have certified this code working using the newly added xUnit tests for both ObservableCollection<T> and Collection<T>.

Looking forward to everyone's feedback on this

[dnfclas]

All CLA requirements met.

[SkyeHoefling]

The build is failing due to CoreCLR components, while this is my first PR for .NET Core after reading the docs it appears that the linked PR in dotnet/coreclr#23018 needs to be merged first then the builds should start passing.

If there is anything else I need to do for this, let me know.

[justinvp]

I've seen subclasses of Collection<T> and ObservableCollection<T> in the wild that override InsertItem and SetItem to validate all the items added to the collection.

For example, the following subclass prevents null from being added to the collection:

public class NonNullCollection<T> : Collection<T> where T : class
{
    protected override void InsertItem(int index, T item)
    {
        if (item is null) {
            throw new ArgumentNullException(nameof(item));
        }
        base.InsertItem(index, item);
    }

    protected override void SetItem(int index, T item)
    {
        if (item is null) {
            throw new ArgumentNullException(nameof(item));
        }
        base.SetItem(index, item);
    }
}

Now that we're adding new ways to Add/Insert items in these collections, I'd love to see some tests that verify we're not unknowingly opening a hole that callers could use to bypass such validation.

For Collection<T>, a test like:

[Fact]
public void AddInsert_NonNullCollection_Throws()
{
    var collection = new NonNullCollection<string>();
    Assert.Throws<ArgumentNullException>(() => collection.Add(null));
    Assert.Throws<ArgumentNullException>(() => collection.Insert(0, null));
    Assert.Throws<ArgumentNullException>(() => collection.AddRange(new string[1]));
    Assert.Throws<ArgumentNullException>(() => collection.InsertRange(0, new string[1]));
}

internal class NonNullCollection<T> : Collection<T> where T : class
{
    protected override void InsertItem(int index, T item)
    {
        if (item is null) {
            throw new ArgumentNullException(nameof(item));
        }
        base.InsertItem(index, item);
    }

    protected override void SetItem(int index, T item)
    {
        if (item is null) {
            throw new ArgumentNullException(nameof(item));
        }
        base.SetItem(index, item);
    }
}

And for ObservableCollection<T>, a test like:

[Fact]
public void AddInsert_NonNullObservableCollection_Throws()
{
    var collection = new NonNullObservableCollection<string>();
    Assert.Throws<ArgumentNullException>(() => collection.Add(null));
    Assert.Throws<ArgumentNullException>(() => collection.Insert(0, null));
    Assert.Throws<ArgumentNullException>(() => collection.AddRange(new string[1]));
    Assert.Throws<ArgumentNullException>(() => collection.InsertRange(0, new string[1]));
}

internal class NonNullObservableCollection<T> : ObservableCollection<T> where T : class
{
    protected override void InsertItem(int index, T item)
    {
        if (item is null) {
            throw new ArgumentNullException(nameof(item));
        }
        base.InsertItem(index, item);
    }

    protected override void SetItem(int index, T item)
    {
        if (item is null) {
            throw new ArgumentNullException(nameof(item));
        }
        base.SetItem(index, item);
    }
}

This way, if the implementation of Collection<T> or ObservableCollection<T> is tweaked, or optimizations added, the tests will ensure we're not unknowingly opening up an unwanted hole.

[SkyeHoefling]

@justinvp thanks for all the great feedback. I am going to look into adding test coverage for NonNullCollection<T> as you recommended

[justinvp]

@ahoefling, apologies for all my piecemeal comments. I haven't had much time to look at this (particularly this week), but I am interested in seeing it come together correctly. Thanks for working on it and being receptive to the feedback.

[justinvp]

Some more comments. I haven't looked at the tests yet.

[SkyeHoefling]

@justinvp I updated the PR to handle several the instances you mentioned in review. I think we have everything covered now. Let me know if there is anything else you think should be fixed.

I also rebased this PR with all the changes that have made it into master which include the PR that was merged from the dotnet/coreclr.

@ahsonkhan @safern - Let me know if there is anything else I need to do this PR.

[SkyeHoefling]

@safern @ahsonkhan I was looking through the files changed and noticed there is a lot of things included now that I rebased this branch.

I thought that was what I was supposed to do, did I miss something?

[SkyeHoefling]

@justinvp @safern @ahsonkhan I am planning to get to these changes today. I am looking for some feedback on how to properly fix the PR. The history got messed up when I thought I needed to rebase. Should I try a squash at this point? Is there a doc that gives guidance on updating a PR to make sure I follow the correct process?

[safern]

@justinvp @safern @ahsonkhan I am planning to get to these changes today. I am looking for some feedback on how to properly fix the PR. The history got messed up when I thought I needed to rebase. Should I try a squash at this point? Is there a doc that gives guidance on updating a PR to make sure I follow the correct process?

It seemed like your rebase got messed up. What I would do is the following:

Squash all of your commits into 1 commit.
Checkout a new branch that is up to date with master.
Cherry-pick your new commit (which is a squash of all of them)
Reset your PR's branch to this new branch.

After squashing your commits into 1 follow

git checkout -b temp
git fetch <remote-to-dotnet/corefx> master
git reset --hard <remote-to-dotnet/corefx>/master
git cherry-pick <sha-squashed-commit>
git checkout -b observablecollection_addrange
git reset --hard temp
git push upstream observablecollection_addrange -f

[SkyeHoefling]

@safern this is perfect and just the advice I was looking for. I had a couple ideas but wanted to get clarification before proceeding

[SkyeHoefling]

@safern gotta love using the force push command when fixing messed up branches. 👍

@justinvp I took all of your feedback and implemented it in the latest revisions. We were able to make all the changes you requested.

@safern @ahsonkhan - I think the PR is good at this point (or so I hope). I am waiting for dotnet/coreclr#23166 to be mirrored over. If we merge this prior to that change being mirrored we will have 1 unit test fail. I assume that code will be mirrored over by Monday and I can make the final update to this PR then.

[SkyeHoefling]

I have rebased the PR with the latest changes and all the tests are passing.

[SkyeHoefling]

@safern is there anything else I need to do with this PR?

[safern]

Failure is unrelated: https://github.com/dotnet/corefx/issues/37054

Thanks for all the hard work @ahoefling

[safern]

@terrajobst how can we get this into NS2.1 now?

[SkyeHoefling]

AWESOME! I was panicking the failure was something I needed to still fix but ran out of time at the airport. This is the best landing from the air travel I just turned my phone back on news

[softlion]

I should say that this will not improve anything.
Property changed notifications will still be emitted for each insertion or deletion which will overload any subscriber.
Instead a range notification should be emitted (ie: 1 notification ONLY for all contiguous insertions, deletions or replacement).

Worst, lots of us already implemented such methods with range notifications. This will prevent those implementations from compiling.