- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 18 Apr 2013 10:33:47 -0700
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: "www-dom@w3.org" <www-dom@w3.org>
On Thu, Apr 18, 2013 at 8:34 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: > 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. Well, it'll be a silent error - you just wont' get any progress updates with the latter call pattern, because chained futures can't make progress. > 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. The potential problem is code that distinguishes between Futures and non-Futures and takes different paths, and uses direct prototype equality rather than instanceof to do that distinguishing. An API switching from Future to ProgressFuture (assuming it's a subclass) would break that code. This possibility is small, but real. ~TJ
Received on Thursday, 18 April 2013 17:34:36 UTC