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

On 18/04/13 19:33, Tab Atkins Jr. wrote:
> 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.

The error might be silent but .progress() callbacks wouldn't be called.
We can except that this should get the developer's attention.

>> 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.

I think we actually expect developers to check if an object is
'thenable' instead of checking the prototype. Otherwise, any non-DOM
Future would be dismissed but there are already a ton of
content-implemented Futures.

--
Mounir

Received on Friday, 19 April 2013 10:36:29 UTC