Retrocausality is possible

[lorentey]

Issue #5 disallows updates to an Observable from inside its own observers, but observers may still synchronously modify the state of other parts of the system.

This means that an observer to variable a is free to directly update the value of variable b, causing b's observers to be notified of the change immediately, even though a may not have finished notifying all of its observers of the original change. If an object was subscribed to both variables, it may thus receive b's notification before it sees the change to a that caused it — it may observe the effect before the cause!

Such retrocausality is against FRP's principles, but it may not actually cause serious problems. Find out if it needs to be fixed.

[lorentey]

Note that since GlueKit implements transactions with dirty reads (issue #2), the state of the system is immediately updated and remains consistent; it is only the change notifications that may arrive out of order.

[lorentey]

I can imagine e.g. ArrayMappingForArrayField getting somehow confused by having the change notification for one of the component arrays arrive before the change to the array-of-arrays itself.

A quick reading of the source indicates that's not the case, but correct reasoning about causality may easily become a casualty of such an overly casual approach.

[lorentey]

My hunch is that this is a complete non-issue, as long as newly registered observers will not see outdated changes that were already applied to the state at the time they registered.