Remove the IList from IReactiveList<T>

[haacked]

This should not have been on the generic interface. It only belongs to
the generic implementation.

Fixes #427

[anaisbetts]

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

[jlaanstra]

Mmm, the fact that we lose ICollection looks strange to me.

Maybe we should make IReactiveCollection<T> no longer inherit IReactiveCollection?

IReactiveCollection can then inherit from ICollection. In addition we could add an IReactiveList interface that would extend IReactiveCollection with IList. This also solves the ambiguity and looks much cleaner to me.
It makes the interfaces look more like the ones already in the BCL.

That would result in this:

public interface IReactiveCollection : ICollection, IReactiveNotifyCollectionChanged, IReactiveNotifyCollectionItemChanged, INotifyPropertyChanging, INotifyPropertyChanged, IEnableLogger
{
}
public interface IReactiveCollection<T> : ICollection<T>, IReactiveNotifyCollectionChanged<T>, IReactiveNotifyCollectionItemChanged<T>, IEnableLogger
{
}
public interface IReactiveList<T> : IReactiveCollection<T>, IList<T>
{
}
public interface IReactiveList : IReactiveCollection, IList
{
}
public class ReactiveList<T> : IReactiveList<T>, IReactiveList, IReadOnlyReactiveList<T>
{
}

What do you think about this? I will create a pull request but I am curious what you guys think about this change before I create one.

[haacked]

Nah, there's a very good reason for this that actually maps to BCL types
well. I'll write up a longer explanation later.

It may well be the real "problem" is IReactiveCollection should be
IReactiveEnumerable.

On Tuesday, December 10, 2013, Johan Laanstra wrote:

Mmm, the fact that we lose ICollection looks strange to me.

Maybe we should make IReactiveCollection no longer inherit
IReactiveCollection?

IReactiveCollection can then inherit from ICollection. In addition we
could an IReactiveList interface that would extend IReactiveCollectionwith
IList. This also solves the ambiguity and looks much cleaner to me.
It also makes the interface look more like the ones already in the BCL.

That would result in this:

public interface IReactiveCollection : ICollection, IReactiveNotifyCollectionChanged, IReactiveNotifyCollectionItemChanged, INotifyPropertyChanging, INotifyPropertyChanged, IEnableLogger{}public interface IReactiveCollection : ICollection, IReactiveNotifyCollectionChanged, IReactiveNotifyCollectionItemChanged, IEnableLogger{}public interface IReactiveList : IReactiveCollection, IList{}public interface IReactiveList : IReactiveCollection, IList{}public class ReactiveList : IReactiveList, IReactiveList, IReadOnlyReactiveList{}

What do you think about this? I will create a pull request but I am
curious what you guys think about this change before I create one.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/430#issuecomment-30240523
.

[haacked]

Yeah, perhaps a better name for IReactiveCollection is IReactiveEnumerable. It serves as the base interface for reactive "collections".

In a way, this is analogous to how IReadOnlyCollection<T> doesn't implement ICollection and neither does ICollection<T>. This is because ICollection defines the Count property and so does IReadOnlyCollection.

However, if we could redo the base interfaces, I would probably make add an IReadOnlyCollection and have ICollection implement that and simply add the Add methods.

However, this wasn't done that way because the read only stuff came later.

Long story short, I think it'll be way more common that we'll have APIs that want to be able to handle any reactive collection (aka IReactiveCollection) than ICollection. Under your proposal, there's no base reactive collection interface. IReactiveCollection is that interface. As I mentioned before, perhaps a better name is IReactiveEnumerable to express that. I'm not opposed to that name change, I just don't feel strongly about it either way.

[jlaanstra]

I modified my proposal and created a PR to move the discussion to its own thread #432.

[jlaanstra]

In a way, this is analogous to how IReadOnlyCollection doesn't implement ICollection and neither does ICollection.

I was not aware of this, but it makes sense in that case.

It may well be the real "problem" is IReactiveCollection should be
IReactiveEnumerable.

The way I understand the readonly BCL interfaces naming, is that IReadOnlyEnumerable was a silly name and they therefore chose IReadOnlyCollection<T>. Because IReactiveCollection<T> implemented ICollection<T>, I thought of it as an ICollection type, which was clearly wrong. That is fixed in my PR #432, so I think it is fine to stick with IReactiveCollection<T>.

[haacked]

The way I understand the readonly BCL interfaces naming, is that IReadOnlyEnumerable was a silly name and they therefore chose IReadOnlyCollection<T>.

Heh, that was my reasoning as well for IReactiveCollection. :)