Re: A Challenge Problem for Promise Designers

Le 26/04/2013 17:25, Tab Atkins Jr. a écrit :
> On Fri, Apr 26, 2013 at 3:19 AM, David Bruant <bruant.d@gmail.com> wrote:
> Your abstract example was:
>> If Future<Future<x>> can exist, then you'll have to write this
>> boilerplate code in a lot of places:
>>      f.then(function res(v){
>>          if(Future.isFuture(v)){
>>              v.then(res);
>>          }
>>          else{
>>              // actual work with the resolved value.
>>          }
>>      })
> I don't understand why this boilerplate code has to exist, or why it
> does anything useful for you.  Fundamentally, your example seems to
> show you having to react to a *badly-authored outside environment*,
> where somebody fucked up and double-wrapped a value by *accident*.
No, please read the last part of [1].
A function can change of signature. That happens anytime a then callback 
used to return a non-promise value and suddenly returns a promise 
because the computation moved from local to remote. So changing from
     p.then(v =>{ return someLocalComputation()+v; })

to
     p.then(v => { return someRemoteComputation().then(x => x+v) })

Such refactoring happens and isn't an accident.
If flattening doesn't happen, all consumers of the next promise have to 
add unwrapping boilerplate.

> This is exactly like arguing that Array#map needs to fully flatten, in
> case people accidentally pass in [[1, 2, 3]].
Some APIs will flatten nested arrays. It depends on the use case.
In that instance, no one has really provided concrete use cases where 
that would be useful for promises beyond writing a flattening 
abstraction or such.
The best argument I've heard so far was from Andreas and it's solved if 
the low-level API is provided.
It doesn't make it less useful to have flattening by default.

> The main reason people have given for this potentially happening is
> authors mixing promise libraries, and the libraries not recognizing
> each other's promises
That's something I didn't talk about during the flattening discussion 
(until realizing both issues are actually connected) and chose to 
completely ignore as I actually am in disagreement with others on that 
point (though I'll probably have to resolve myself to accepting it by 
lack of better idea).
My arguments are in the realm of software engineering, like ease of 
refactoring, code maintainability, readability.

> If you get stacked promises *on purpose*
What are the use cases where you want that besides when writing a 
promise abstraction (like flattening)?

> then obviously you don't
> want to break the feature by having .then() recursively unwrap.
>
> I would *love* to see a concrete example of a nested promise problem
> that's not a result of an authoring error (which seems hard to do on
> its face - at least with Futures, it seems *difficult* to accidentally
> double-wrap)a weird non-JS environment (like Dean Tribble's example,
> which turned out to be invalid for JS promises and DOM Futures), or a
> mixing of major libraries with bespoke promises that don't mutually
> recognize each other (because this will go away reasonably fast now
> that we have standardized Futures).
Refactoring and not having to rewrite/add boilerplate all the promise 
consumer.

I would *love* to see a concrete example of a nested promise use case 
that isn't an abstraction that better belongs in a library.

David

[1] https://mail.mozilla.org/pipermail/es-discuss/2013-April/030232.html

Received on Friday, 26 April 2013 17:03:24 UTC