Defined classes for 4 collection types: Set, Cache, Dictionary, and List, matching the previously-defined interfaces.
Defined ChangeTrackingXXX classes for each collection type. These classes mimic the ChangeAwareXXX classes from DD today, and form the core of each SubjectXXX class, as well as a great basis for implementing operators, going forward.
Defined SubjectXXX classes for each collection type. These classes mimic the SourceXXX classes from DD today, and are the main public API for building change streams.
The SubjectXXX can be extended or decorated in the future to add different levels of concurrency and thread-safety. This should allow consumers who don't need thread-safety to get more performance out of the library, and those who do need it to opt into it.
There were a few things I cleaned up across the collection interfaces, including the following:
A bunch of spots where collections were defined as IObservable<> of changes, rather than change sets.
Some naming for range methods, to avoid some ambiguous resolution issues I had.
After some discussion in Slack, re-defined Dictionary and Cache to support AddOrReplaceRange() instead of AddRange(). This eliminates the possibility for corrupt collection states to occur, in the event of key mismatches by the consumer, and mimics how SourceCache<> behaves in DD today.
Split out all collection mutation methods not related to change publishing into IExtendedXXX<> interfaces, to allow for ChangeTrackingXXX collections to be defined.
Main points:
Set,Cache,Dictionary, andList, matching the previously-defined interfaces.ChangeTrackingXXXclasses for each collection type. These classes mimic theChangeAwareXXXclasses from DD today, and form the core of eachSubjectXXXclass, as well as a great basis for implementing operators, going forward.SubjectXXXclasses for each collection type. These classes mimic theSourceXXXclasses from DD today, and are the main public API for building change streams.SubjectXXXcan be extended or decorated in the future to add different levels of concurrency and thread-safety. This should allow consumers who don't need thread-safety to get more performance out of the library, and those who do need it to opt into it.There were a few things I cleaned up across the collection interfaces, including the following:
IObservable<>of changes, rather than change sets.AddOrReplaceRange()instead ofAddRange(). This eliminates the possibility for corrupt collection states to occur, in the event of key mismatches by the consumer, and mimics howSourceCache<>behaves in DD today.IExtendedXXX<>interfaces, to allow forChangeTrackingXXXcollections to be defined.