W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Future cancellation

From: Juan Ignacio Dopazo <dopazo.juan@gmail.com>
Date: Wed, 1 May 2013 11:30:03 -0300
Message-ID: <CA+ejddWFE4R94Kg4d9W3-1nmYHd9S3cmu3YeQSiTm+qpVZKA5A@mail.gmail.com>
To: Kevin Smith <zenparsing@gmail.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
2013/5/1 Anne van Kesteren <annevk@annevk.nl>

> On Wed, May 1, 2013 at 10:45 AM, Alex Russell <slightlyoff@google.com>
> wrote:
> > This is what I've sketched in various places, including for Anne WRT
> XHR. I
> > suppose (without any cause) that folks would pick up on the idea that the
> > minimal Future superclass was being explicitly designed to be
> subclassable
> > to address issues like this and progress notification. Perhaps we need to
> > call it out more explicitly in the spec?
>
> The specification does need to address that better, in particular what
> then() and catch() might return for subclassed futures. We found use
> cases both for returning a new instance of the subclassed future
> itself (ProgressFuture) and simply returning a new "base" future (for
> the crypto APIs).


For YUI we tried something like:

then(callback, errback) {
  return new this.constructor(function (resolver) {
    // ...
  });
}

While it is true that there are use cases for both, there are use cases
that get broken when returning a instance of the subclass. For example, a
LazyPromise which runs the initialization function only when then() is
called, breaks down with this approach. It seems to me that if some use
cases break and for others the same effect can be achieved using a
different approach, then the safest path should be taken. That seems to be
only returning "base" promises from then().

2013/5/1 Kevin Smith <zenparsing@gmail.com>

>
> I think this difficulty points to a deeper issue with attempting to make a
>> promise something other than a placeholder for a value.
>
>
The fact is that in a way promises are already a representation for a value
and for an operation. What is a promise for undefined? Let's say I have a
database object with a close() method that works asyncronously. If close()
returns a promise, which value does it represent?


As for cancellation, I worry about the ergonomics of returning { promise,
cancel } pairs. Like Alex mentioned, a subclass makes a lot more sense for
XMLHttpRequest. And if it works for XHR why shouldn't it work for other
promises?

Juan
Received on Wednesday, 1 May 2013 14:30:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC