Specify dispatch order

[raimohanska]

It's now a well-known secret that Bacon sends events out to subscribers in the order of subscription. For example,

b = new Bacon.Bus()
b.onValue(-> console.log("1"))
b.onValue(-> console.log("2"))
b.push()

always prints 1,2 (never 2,1).

This is, however, unspecified behavior without tests. Let's make it specified and documented behavior, shall we?

[phadej]

Isn't this order of effects something you don't really want rely on, i.e. document as undefined behaviour = implementation detail. Like an order of evaluation of function parameters in C. I guess there is something wrong with overall application design, if dispatch order matters.

[raimohanska]

There are indeed cases where you want your side-effects to occur in a specific order. Currently there's no better way to ensure this but rely on dispatch order, or bundle them all in a single subscribe.

Personally, I've never needed this though, so I don't have a strong opinion on this.

Thoughts?

[RoboTeddy]

I wonder if we should add tests but not documentation, in order to encourage people to structure their side effects sanely. Reliance on subscription order could obscure the fact that order of execution matters (especially if sometimes it matters, and sometimes it doesn't).

(Or we could document it with caveats/recommendations.)

observable.onValue callEach(fn, fn2, fn3) might be a more legible approach for some cases. I've never needed this either, though.

On Sunday, December 15, 2013, Juha Paananen wrote:

There are indeed cases where you want your side-effects to occur in a specific order. Currently there's no better way to ensure this but rely on dispatch order, or bundle them all in a single subscribe.

Personally, I've never needed this though, so I don't have a strong opinion on this.

Thoughts?

— Reply to this email directly or view it on GitHubhttps://github.com/baconjs/bacon.js/issues/292#issuecomment-30640448 .

[mkaemmerer]

I am in favor of both tests and docs.

Here's my reasoning:

Suppose for some reason, you decide that it would be better to have subscriptions called in reverse order, and you make the change. Chances are the change will break someone's program as a result, and therefore, it should require a new major version number. If the major version number changes, I would expect some documentation of what changed and what I need to do to ensure compatibility with the new version.