I wanted to share some further thoughts that I originally wrote up in a separate thread to hopefully clarify my position:
In the context of SE-0395, it seems to me that, the intended primary purpose seems to be 'fulfilling the needs of GUI apps' as that was the context given by the proposal – but perhaps the aim was more general.
For me, I would like a cohesive solution, the parts of which can be used together seamlessly; using SE-0395's proposed
ObservationTracking mechanism, should work well when also using the
One example of what I mean by this is that: if I have some
View directly observing a property on each of
ObservableB using the
ObservationTracking mechanism, then
ObservableA also directly observes some property on
ObservableB (a dependent property) using whatever the
ObservedValues mechanism becomes, they all need to be able to synchronise in the current event loop cycle.
As SE-0395 is currently proposed, when
ObservableB is updated, triggering both an observation event on the
View will receive its event in the current event loop cycle, while
ObservableA will receive its update (via an async sequence) in some future event loop cycle. So ultimately the
View will receive updates for this single update across multiple event loop cycles.
Cue 'Flickery UI's.
This is what I mean when I'm talking about invariants. (In this context, at least.) I realise that invariants can still be temporarily broken in the current frame/event loop cycle, but I think that's a lot easier to reason about than invariants broken across multiple frames/event loop cycles.
I do wonder if the attempt to combine both 'fulfilling the needs of GUI apps' and inter-actor observation in the same mechanism is perhaps too ambitious. Not quite satisfying either goal. Perhaps focusing the proposal on a more specific goal would lead to a better overall solution. Then, as part of a future direction, it can be considered whether or not the mechanism can be successfully expanded to achieve inter-actor observation without compromising the existing primary purpose.