IMO, cancelation is not appropriate for promises/futures. (sticking with the name "promises", sorry for the distraction).
Promises represent a value, but have no knowledge of the work involved to get the value. The work knows about the promise, the promise doesn't know about the work. If you want to externalize additional controls to allow your code to steer the work involved in getting the promised value, that is justification for a separate class that contains a promise, likely exposing a 'then()' method linked to its internal promise. The code used to set up the resolve/reject conditions can externalize the reject method to enable cancelation for instances of that class. But the promise remains limited to a value proxy. The more a class needs to know about the work, the more specialized the class becomes, which Promise has avoided pretty well so far. Luke On Apr 29, 2013, at 6:57 PM, Ron Buckton <[email protected]> wrote: > I’ve created separate gists for three different ways that I am currently > investigating as a means to support the cancellation of a Future. These can > be found here: > > 1. Cancellation using Future: https://gist.github.com/rbuckton/5486149 > 2. Cancellation using Future.cancelable: > https://gist.github.com/rbuckton/5484591 > 3. Cancellation using Future#cancel: > https://gist.github.com/rbuckton/5484478 > > Each has a list of some of the benefits and issues I’ve seen while > experimenting with each approach, as well as possible changes to the various > APIs or algorithms for Future to make each happen. > > In general, cancellation of a Future can be beneficial in a number of cases. > One example is the case where you are requesting a resource from a remote > server using XHR. If the request was being made to fetch a page of data, and > the user opted to move to the next page before the current page completed > loading, it no longer becomes necessary to continue fetching the remote > resource. In addition, it is no longer necessary to handle any additional > computation or transformation logic that would have resulted from the > successful completion of the fetch operation. Having the ability to cancel > the request allows an application to quickly release resources that it no > longer needs. > > It is also useful to be able to handle the cancelation of a long running task > that might be executing in a Worker. In this case, cleanup logic that is part > of cancelation would request the worker to close, ending the current > operation and releasing resources. > > Both of the above examples are indicative of cancelling the root of an > operation, but there are also circumstances where you might want to cancel a > chained Future and any Future chained from it, without canceling the root. In > the previous example regarding paged data, I might wish to allow the fetch > operation to complete so that I could cache the data for quick retrieval, but > would only want to cancel any possible UI updates that might occur in a > chained Future. > > I’m interested to hear what others think with respect to properly handling > cancellation with Futures. > > Ron > _______________________________________________ > 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
