Skip to content

Conversation

@JakenVeina
Copy link
Contributor

@JakenVeina JakenVeina commented Jun 8, 2024

Main points:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants