IMO promises should reject if they are "cancelled". The same method that gave you the Promise (for example, an AJAX API) can give you a capability to "cancel" the Promise, ie cancel the pending network operation and reject the Promise (rejecting is a no-op if the operation races with cancellation and manages to resolve first, naturally).
I'm not opposed to setting up a defacto API for the cancellation capability, but I don't think this needs to be part of EcmaScript. If you want to define a `CancelablePromise` subclass which has a `CancelablePromise#cancel()` method, feel free. But I don't think it should be tightly tied to the Promise spec at all. The capability to cancel an operation should be first-class, and able to be passed around independent of the Promise which gives the future result of the operation. I don't think you need to define an "unlisten" API, either. Just discard the resolve/reject capabilities for the Promise in question. The last time I audited the spec, I convinced myself that this would ensure that all chained promises were also garbage and would be safely collected. (The only pointers to chained promises are held by the resolve/reject capabilities.) --scott
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
