Prototype/Proposal for surface of source collections.

[JakenVeina]

Main thoughts:

• Trying to follow and extend upon System.Collections.Generic as much as possible, to leverage everyone's familiarity with all those collections. Names are definitely up for debate. Maybe ReactiveDictionary/ReactiveList or DynamicDictionary/DynamicList instead? I think ReadOnly is definitely the way to go, as opposed to Source/Observable from DD today.
• No equivalent of the .Connect() method, as I think the main thing that accomplishes is avoiding ambiguity between LINQ operators and RX/DD operators, and that can be resolved trivially by leading queries with .AsEnumerable() or .AsObservable().
• I threw in an additional pair of interfaces as the corollary to SourceCache, IObservableCache/IObservableReadOnlyCache as the source collection that has key-management baked in. I rather like the symmetry between that and IObservableDictionary/IObservableReadOnlyDictionary.
• There's room for more overloads of the various mutation methods, particularly all the range methods. E.G. .RemoveRange() that takes items instead of keys, .AddRange() that takes KeyValuePair<>, .AddOrUpdate() and .AddOrUpdateRange(), what have you. I just put in the basic ones that I think are the most appropriate.
• .SuspendNotifications() in the same fashion as what we recently added to DD, since that seemed to work out really nicely.
• I tried to pay special attention to the use of the terms "item" and "value", in the same vein as System.Collections.Generic. Sets, lists, and caches all deal with "items" exclusively, while dictionaries have "items" and "Values" as separate concepts, where an "item" is the combination of both a key and a "value".
• I used IEnumerable<> exclusively for passing ranges of items, because I think we can do what I did in the changeset implementations, and leverage generics and polymorphism in just one written method, to get the equivalent performance of separate methods operating on collection types directly.

[RolandPheasant]

Some quick first thoughts:

ReactiveList

Version 2 of Dynamic Data which was never published was called ReactiveList. I abandoned that name when I discovered RxUI, who at the time had an object called ReactiveList.

Object Naming

It was never my intention to create a facsimilie of List and Dictionary, they just happened to evolve that way. I soon regretted it as people wanted a them to do everything that a list or dictionary does! I much prefer to keep the naming neutral and and use DataSource<T> and DataSource<TObject, TKey>. That way we are free to implement our own interpretation.

No Connect()

Surely there's a convention for this ToObservable() - it was another of my regrets, not just to use that,

.SuspendNotifications()

I suspect that could be really useful.

[JakenVeina]

It was never my intention to create a facsimilie of List and Dictionary

Whereas, for me, I see VALUE in making facsimilies of List and Dictionary. It's not like any methods on the List and Dictionary interfaces are incompatible with our model of changes and changesets, or are hard to implement. And if we don't have the source collections implement IList<>, IReadOnlyList<>, etc. I don't see the implementations being any different.

Surely there's a convention for this ToObservable() - it was another of my regrets, not just to use that,

I'm not really sure what you mean. In your mind, what would .ToObservable() upon a source collection actually do? I don't see any actual use for a .ToObservable() method, except for what I mentioned already, and for that we'd want .AsObservable().

[RolandPheasant]

Ok,

I'll roll with using the notion of List and Dictionary in the semantics for the replacement for Source List / Cache.

But I would add that we should probably think of these 'data sources' as subjects, which is in fact what they are. They are also amendable which is why they require the add, remove methods etc.

Perhaps ListSubject<TItem> and DictionarySubject<TKey, TItem> ? How about AsReadOnly() to hide any edit methods and make these ObservableList<TItem> and ObservableDictionary<TKey, TItem>? Again, close to the original but also semantically inclusive of storage type

... btw you have probably spotted that I am really not a fan of long names!

Also we probably should not get caught up too much on naming because at any time before the first release we can refactor en-mass

You're right regarding .AsObservable() - ignore me on that !

[JakenVeina]

But I would add that we should probably think of these 'data sources' as subjects

That is an excellent way to think about it.

Perhaps ListSubject and DictionarySubject<TKey, TItem> ? How about AsReadOnly() to hide any edit methods and make these ObservableList and ObservableDictionary<TKey, TItem>?

I love it. With the caveat that IObservableList<T> and IObservableDictionary<TKey, TItem> would eliminate the need for an .AsReadOnly() method (or at least, eliminate the need for it to be an allocation). Plus, it still leaves open the opportunity for other implementations of those interfaces. Also, that makes it mirror RX even MORE. Subject<T> implements IObservable<T>, SubjectList<T> implements IObservableList<T>, SubjectDictionary<TKey, TValue> implements IObservableDictionary<TKey, TValue>, etc... Who doesn't love when code rhymes?

Now my head's also wondering if there's value for an IObserverList<T> and IObserverDictionary<TKey, TValue>. Probably not, lol.

[github-actions[bot]]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.