Well-defined ordering for operations

[littledan]

In order to guarantee common behavior across implementations, it would be good to define common orders for how certain operations work, and to test these. Some examples:

• The order of elements in the getPending() array
• When one .set triggers multiple watchers, what order those watcher callbacks are called in
• When one .watch call triggers several watched callbacks, the order of these (ditto unwatch[ed])
• The order of elements in introspectSources/introspectSinks
• When multiple errored computed signals are data dependencies of another computed, and this results in an AggregateError, the order of the errors

While working on defining these details, attention should be paid to whether we are placing a heavy burden on implementations (eg if the requirements lead to less efficient data structures)

[littledan]

@shaylew and I discussed this issue. There are sort of two coherent ways through:

• Order things as sets based on insertion. This is annoying/slow to implement though.
• Order based on a global counter's value when they were allocated. This is somewhat more stable (e.g., if the order of dependencies' access changes in a computed).

What doesn't feel really coherent is the current semantics, where removing things from sets brings something back from the end. This is efficient to implement but feels a little weird.

[shaylew]

When multiple errored computed signals are data dependencies of another computed, and this results in an AggregateError, the order of the errors

Are we doing AggregateError there? I thought we'd just rerun the computed and let whichever one it reads first throw.

We do need AggregateErrors for when multiple watcher callbacks throw during one set operation, and maybe also for watched/unwatched (still need to figure out where those end up IIRC); presumably these should be in the order the throwing userland callbacks ran.