On Tue, Sep 22, 2015 at 4:50 PM, Zibi Braniecki
<zbigniew.branie...@gmail.com> wrote:
> This sort of repeatable-promise, would reduce it to:
> 1) Set the repeatable promise on the target
>
> Sounds like it would make much easier to write async code without logic for
> preventing race conditions.
>
> Is there any other approach to that?
I think it best to just consider promises async program flow: it
completes or errors out. A repeatable promise concept does not seem to
have an analogy with sync program flow (maybe checkpointing a line in
a piece of code and re-winding it to run again?), so I would be more
hesitant to try to fit that into a promise model.
In gaia email, we have an event library[1] that has an
"emitWhenListener" method, so the code that does the emit of the event
can do so via that method, and then when the first event listener
listens for that particular event name, it gets that previously
emitted event. This is only useful if we know there is likely just one
event listener and there may be a race between the emitter and the
listener.
There is also a concept of "latest" in the event library:
evt.latest('foo', function(event){}) will be called when there is a
'foo', and if there is an existing one, called right away, and for
future changes to a 'foo'. This approach works well for multiple
listeners that may be dealing with something that could already have
an existing state.
Maybe the conceptual models in that library could be refined, but they
sound related to what you are asking.
For async concepts, gtor[2] might be an interesting read, but I say
that not having fully grokked the fullness of gtor, and perhaps if I
did it would contradict some of the above.
James
[1] https://github.com/jrburke/evt - light on docs, tests might be the
most instructive.
[2] https://github.com/kriskowal/gtor/
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
