Re-write issues

[Updownquark]

This is to keep track of issues I need to address as I rewrite ObServe.

• Preclude firing Observable events while the previous one is still firing
• Rethink sharing transactables for collections or else allow for event interruption in SimpleObservable
• Need a map-and-cache mechanism on ObservableCollection that calls a function on an element's value and keeps the result in a cache and does not re-invoke the map function unless the underlying value is replaced in the collection. Re-firing the same value would cause the cached collection to re-fire the mapped value without re-invoking the map. Ideally, this would not be a completely new ObservableCollection method. Perhaps the cache() method could be changed to handle performing the map operation. Perhaps the cache() method could be removed altogether and the filter-mapping mechanism could be augmented with caching capability.

[Updownquark]

Perhaps the filterMap mechanism could be expanded to include combination and (value-unspecific) refreshing in addition to caching.

[Updownquark]

Had a thought, may be garbage: Perhaps everything should be cached--all derived collections and values. The derived values would install a weak listener in the values they are derived from. The derived values would have a strong reference to the listener so that the listener is not gc'd while the derived value is reachable. But when the derived value is gc'd, the weak listener would remove itself (the next time it is called). No until observable would be needed.

If the builder pattern started on ObservableCollection.buildMap could be expanded to include combination, refreshing (value-specific as well), and generalized to ObservableValue, this caching would not be wasteful because the results of the derivation would not be middle-men, but useful values.

The builder could produce a structure that produces

• A structure that listens to all the non-element-specific observables relevant to the value or collection (e.g. combination values, non-element-specific refresh observables
• A structure that accepts values for an element (from the source collection or value) and produces derived values or nothing (if that element is filtered out). This structure would be dependent on the non-element-specific structure. The caching would take place in this structure.

The derived value or collection class would instantiate one of the first kind of structures and then one of the second kind per source element. This would maintain the cache and listeners and accessors would only need to reach into the cache. Only modification operations would need to reach into the source value.

flattenValues() could also be implemented in this way. Perhaps a flatMap() method could be added to the builder.

Implement sorted() using a SortedTreeList (need to create).

Perhaps withEquivalence(), filterModification(), takeUntil(), and unsubscribeOn() could all be implemented by the same class.

If all this could be done,

• map, filter, filterMap, combine, combineWith, refresh, refreshEach, and cached would have their functionality rolled in to what is now buildMap
• Only the single collection that implements buildMap, plus an fronted collection implementing the withEquivalence/filterModification/takeUntil functionality, plus 2 flattened collections would be needed to implement all collection derivations.

Need to think really hard about the changes() observables and make them very smart. Maybe add CollectionChangeType.moved

[Updownquark]

The things that are left to do in ObservableCollection

• [x] Think about changes(). Always indexed? Add indexedChanges()?
• [x] ObservableListImpl.SubList
• [x] Flattening
• [x] ObservableCollection.map(Function), ObservableList.map(Function)
• [x] Fix up the Qommons tree collections, adding additional required functionality
• [x] SortedSubSet's element IDs need to subtract their min index
• [x] Associative structures
• [x] Improve DefaultObservableCollection to support the use case where the flow from ObservableCollection.create() could be used to create multiple collections, all mapping to the same DefaultObservableCollection, which would currently create errors
  • [x] Add a map of element ID to current value
  • [x] Support multiple listeners
• [x] Fix BinaryTreeNode navigation performance
• [x] Support external subscriptions from passive listeners
• [x] Decouple ObservableValue and Observable
• [x] ObservableValue.lock()
• [x] ObservableValue.map and .combine options
• [x] Consolidate xform option usage code
• [x] Enable support for MapOptions.elementSetting in passive manager (check on active one too)
• [x] Fix up current tests
• [ ] DefaultObservableGraph intrinsic listener
  • [ ] Make a post-modification action flow for cleanup
• [ ] Test ALL functionality
  • [ ] index modification on BetterSortedSets
  • [ ] Change stamps
  • [ ] Equivalence
  • [x] flattenValue
  • [ ] collectLW()
  • [x] All map options
  • [ ] All combine options
  • [ ] All filterMod options
  • [ ] Intersection
  • [ ] ObservableMap
• [ ] Compress the data flow/listening and spliteration stacks
• [x] Secure flattened locking
• [ ] Profiling

[Updownquark]

I think this can be closed. The testing check marks are obviously now accounted for by the super tester issue, #12. I have done some work to compress the spliteration and listening stacks, but I may do more later. Profiling will probably best be done using the super tester.