W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: [futures] Folding .progress() into .then() for ProgressFuture

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Thu, 18 Apr 2013 17:34:01 +0200
Message-ID: <51701269.9080302@lamouri.fr>
To: www-dom@w3.org
On 12/04/13 01:32, Tab Atkins Jr. wrote:
> Task.js, one of the more popular independent promise libraries,
> handles progress promises by just making .then() take three optional
> callbacks, with the third being the progress callback.
> <http://taskjs.org/#then>
> I think we should adopt this.  You'll commonly want to register your
> progress callbacks at the same time as your success/error callbacks,
> so this is slightly more natural.
> As well, right now it's easy to accidentally register your callbacks
> in the wrong order when chaining and get the wrong results - the
> correct way to register both is always:
> fu.progress(cb).then(cb,cb)
> If you do it in the opposite order, like:
> fu.then(cb,cb).progress(cb)
> you won't be listening to progress updates from fu, but rather from
> the chained future returned by .then.  Given that the chained future
> is always a plain Future afaict, and thus '.progress' will return
> undefined, this is not what you want.  ^_^

Given that Future is all about natural chaining of async instructions,
it should be natural for a developer to do fu.progress().then() instead
of fu.then().progress().
Also, as you said, calling the methods in the wrong order will lead to
an error which should hopefully be visible enough for the developer to
fix his/her code.

> As a further step, Task.js just makes all promises able to post
> progress updates, rather than making it a special kind of promise you
> have to request.  This sounds like it may be a good idea - by default,
> futures just won't post any progress updates, so the third callback
> won't do anything.  This is also friendlier to later "upgrading", if
> we decide that a particular API originally specified as a plain Future
> should post progress updates - right now it'll require a prototype
> change, which has compat impact.

I do not see any particular retro-compatibility problem in switching
from Future to ProgressFuture given that ProgressFuture is a super-set
of Future. The opposite might be true though switching from
ProgressFuture to Future would break but I guess such move shouldn't
happen too.

Received on Thursday, 18 April 2013 15:34:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC