Promises, the middle state : negociation

Michaël Rouges michael.rouges at gmail.com
Thu May 15 02:33:59 PDT 2014


Hi all,

As I totally agree that a promise can only be resolved or rejected once ...
so I think his behavior is perhaps too black or white.

As IRL, when we receive a promise, we expect that the author makes every
effort to resolve it, by any way.

Progammatically, we can wish the same.

By example, we can have :

   - an error to ignore
   - an error that requires to execute other operations leading to
      - a rejection
      - a continuation
      - a retry

To cover all these cases, in the current promises state, we can have (a
quite) complex promises, easily solvable.

My idea? the negociation, where the goal is to find a solution to resolve
it (rejection reduction).

For the promise "fn" argument, to add an optional "negociate" argument.

```
promise = new Promise(function (resolve, reject, negociate) {
// the promise body
});
```

An the related Promise.negociate method like :

```
Promise.negociate = function negociate(resolve, reject, negociate, retry,
value) {
};
```

That returns a promise, negociable too, where :

   - resolve is shared with the original promise (that contains the
   negociate call) to continue the process
   - reject is shared with the original promise (that contains the
negociatecall)
   - negociate, it's own negociation, for multiple attempts/behaviors
   - retry to recall the original promise fn argument (compliant with the
   promises concept, since our promise was neither rejected nor resolved,
   at this point)
   - value (or values, I'm not sure) to pass some infos/tools that we need
   to take our decision, in the negociation process


Lemme your advices. ;)

Michaël Rouges - https://github.com/Lcfvs - @Lcfvs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140515/91fe3c5e/attachment.html>


More information about the es-discuss mailing list