Why not just use a subclass of Promise? I don't see why that has to be
part of the base class.
```
class ObservablePromise extends Promise {}
ObservablePromise.prototype.isSettled = function() { return
!!this.isSettled; };
ObservablePromise.prototype.then = function(res, rej) {
return super.then(
function(x) { this.isSettled = true; return res(x); },
function(e) { this.isSettled = true; return rej(x); }
);
}
// etc
```
--scott
On Mon, Jun 1, 2015 at 5:29 PM, Ron Waldon <[email protected]> wrote:
> I have lodged the following question on StackOverflow:
>
> http://stackoverflow.com/questions/30564053/how-can-i-synchronously-determine-a-javascript-promises-state
>
> I have also lodged it as a proposal on Specifiction:
>
> http://discourse.specifiction.org/t/how-can-i-synchronously-determine-a-javascript-promises-state/866
>
> I have a pure JavaScript Promise (built-in implementation or poly-fill):
>
> `var promise = new Promise(function (resolve, reject) { /* ... */ });`
>
> From the [specification](
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects),
> a Promise can be one of:
>
> - 'settled' and 'resolved'
> - 'settled' and 'rejected'
> - 'pending'
>
> I have a use case where I wish to interrogate the Promise synchronously
> and determine:
>
> - is the Promise settled?
> - if so, is the Promise resolved?
>
> It appears there is no API for synchronous interrogation of a Promise's
> state. Can we please make this part of a future specification?
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
