Open API Tasks

[Updownquark]

• [ ] Make ObservableMultiMap.values() observable
• [x] ObservableSet dynamic repair. Should calls this API do anything or possibly just be ignored?
• [x] Non strict mapped value setting. E.g. having a double-typed value mapped with x5 and available /5 reverse may frequently forbid a set operation because x/5*5 != x. In cached situations, this could be accommodated directly by storing the set value and applying it when the update from the source comes through. For non-cached, there should at minimum be a strict boolean on the cache options that would allow these kinds of operations even if the final value is not identical to the one set.

[Updownquark]

I've added the allowInexactReverse method in the new Transformation API. It is only allowed with mapping, not combination, because of some surprises I encountered when attempting to test it. These are commented on and documented in the source, but I'll reproduce it here for posterity.

In distinct managers deriving from inexact-mapped collections, values may be added as other than the actual argument. To account for this, the map used to store values must be aware of this condition. This is done by using the mapping equivalence in this particular case. However, if a value used in a combination is changed, the equivalence would then change, potentially corrupting any sets and maps created with it.

[Updownquark]

(In reference to above comment regarding the strict mapping task)

However, this problem only exists for collections. Values, which now use the same transformation API, should not have any problems with equivalence, so they should not, as they are now, be prevented from using inexact matching for combination.

[Updownquark]

I'm going to mark the ObservableSet dynamic repair task as complete. The ObservableSet supports repair any time a value is changed. If there is some value or condition that can possibly affect value storage in the set, a flow.refreshOn() should be used underneath (before) the distinct() call to keep the set correctly stored. Exposing an explicit call to effect repair is somewhat problematic with the Observable API because of the support for unmodifiability. So I think the best solution to to just keep the current status quo, which is to ignore repair calls.

[Updownquark]

There are some very difficult problems with making ObservableMultiMap.values() observable. In particular, ObservableCollections must be indexable. The core event they fire contains the index of the added/removed/changed element. Since values() combines elements from several collections, it's very difficult to access the index of one element in the whole values() collection without iterating over each previous multi-entry and adding up the sizes. There's not a very good accounting method I can think of to do this quicker.

For now, I'm giving up on that and marking this issue closed, since the others are done.