Re: Promises: final steps

Let's put done back in. It's the right thing.

/be

> Boris Zbarsky <mailto:bzbarsky@MIT.EDU>
> September 5, 2013 7:55 PM
>
>
> Also fwiw, likewise. The clearly spells out the "if I don't get to 
> here, something went wrong and I want to know what" bits....
>
> -Boris
>
> Mark Miller <mailto:erights@gmail.com>
> September 5, 2013 10:15 AM
> On Thu, Sep 5, 2013 at 12:04 PM, Domenic Denicola 
> <domenic@domenicdenicola.com <mailto:domenic@domenicdenicola.com>> wrote:
>
>     From: Kevin Smith [zenparsing@gmail.com <mailto:zenparsing@gmail.com>]
>
>     > Indeed, for a non-GUI embedding like Node, they *must* be
>     debuggable using just a console.
>
>     This is an important point. A provisional idea that preserves our
>     desire to not introduce new features to promises themselves,
>     requiring user choice at authoring time, might be some kind of
>     `console.unhandledRejections()` function which returns you a
>     snapshot of the current unhandled rejections bucket.
>
>
> That would be a global communications channel.
>
>
>     > Another option is a static method which takes a promise and
>     throws rejections ala done:
>     >
>     > ```js
>     > Promise.throw(makeSomePromise.then(...));
>     > ```
>
>     I find these kind of things confusing. RSVP did something similar,
>     introducing
>
>     ```js
>     RSVP.rethrow = r => setImmediate(() => throw r);
>     ```
>
>     so that you write
>
>     ```js
>     somePromise.then(...).catch(RSVP.rethrow); // actually RSVP uses
>     `fail`.
>     ```
>
>     It's not clear to me why this, or your `Promise.throw`, is better than
>
>     ```js
>     somePromise.done(...)
>     // or
>     somePromise.then(...).done()
>     ```
>
>
> As I said, I think we will eventually add something that provides this 
> or similar functionality. But it does not need to be added to the 
> subset this repository seeks to define -- for the immediate needs of 
> DOM. Since the topic of this thread is "final steps", I'm just trying 
> to be clear in this context that this .done-ish issue is after these 
> "final steps".
>
> This is the kind of issue that is best decided after more experience 
> with several of these debugging aids, in both browser and server. So 
> we should of course continue to discuss these options on es-discuss 
> regarding ES7. Also, we won't have Weak References until ES7, and that 
> bears on this discussion and expected experience. FWIW, so far, I 
> still like .done better than the suggested alternatives.
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> -- 
> Text by me above is hereby placed in the public domain
>
> Cheers,
> --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Domenic Denicola <mailto:domenic@domenicdenicola.com>
> September 5, 2013 9:04 AM
> From: Kevin Smith [zenparsing@gmail.com]
>
>> Indeed, for a non-GUI embedding like Node, they *must* be debuggable using just a console.
>
> This is an important point. A provisional idea that preserves our desire to not introduce new features to promises themselves, requiring user choice at authoring time, might be some kind of `console.unhandledRejections()` function which returns you a snapshot of the current unhandled rejections bucket.
>
>> Another option is a static method which takes a promise and throws rejections ala done:
>>
>> ```js
>> Promise.throw(makeSomePromise.then(...));
>> ```
>
> I find these kind of things confusing. RSVP did something similar, introducing
>
> ```js
> RSVP.rethrow = r =>  setImmediate(() =>  throw r);
> ```
>
> so that you write
>
> ```js
> somePromise.then(...).catch(RSVP.rethrow); // actually RSVP uses `fail`.
> ```
>
> It's not clear to me why this, or your `Promise.throw`, is better than
>
> ```js
> somePromise.done(...)
> // or
> somePromise.then(...).done()
> ```
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Kevin Smith <mailto:zenparsing@gmail.com>
> September 5, 2013 7:10 AM
> Hi Kris,
>
> Thanks for the details! This gives us an idea what a "promise 
> monitoring" feature might look like in a browser's developer tools. I 
> think such a feature would be really cool, but I believe that 
> promise-using programs ought to be debuggable using just a console. 
> Indeed, for a non-GUI embedding like Node, they *must* be debuggable 
> using just a console.
>
> I don't think we should ship an API that is not debuggable using a 
> console. However, I'm *not* in favor of a `done` method on the Promise 
> prototype because of functional overlap with `then`.
>
> Another option is a static method which takes a promise and throws 
> rejections ala done:
>
> Promise.throw(makeSomePromise.then(...));
>
> Personally, I consider it a shame that promise libraries punted on the 
> distinction between rejections and program errors, but I suppose it's 
> too late to go there.
>
> { Kevin }
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Kris Kowal <mailto:kris.kowal@cixar.com>
> September 4, 2013 12:15 PM
> My colleagues and I are working on an extension for Chrome Web 
> Inspector that can communicate with promise libraries, particularly Q, 
> over the window message port. The tool, which will be renamed and 
> rewritten before it is ready for general use, adds a Promises tab to 
> Web Inspector that shows all currently pending and unhandled 
> asynchronous errors, as well as stack traces for both, and also 
> progress information, albeit determinate, indeterminate, or 
> indeterminate but lively. There is a video accompanying for demonstration.
>
> https://github.com/montagejs/continuum
>
> https://www.dropbox.com/s/2h68ax9j5mj7i6c/continuum.mov
>
> The promise client broadcasts when a promise is deferred, when a 
> deferred promise is resolved, when a deferred promise makes progress 
> (through the `deferred.notify` interface), when a fulfilled promise is 
> created, when a rejected promise is created, and when a rejection is 
> handled. As such, the inspector can reconstruct whatever portion of 
> the program’s promise history it elects to retain.
>
> In time, I intend to formalize a protocol. Ideally this system would 
> be useful for both “primordial” and library promises, and combinations 
> of both. Of course, any assistance would be valuable.
>
> Also, ideally this would approach the functionality available to 
> Causeway and perhaps even *become* a manifestation of Causeway.
>
> https://code.google.com/p/causeway/wiki/CausewayIntroduction
>
> It would certainly be possible to show promises in multiple contexts, 
> including cross-origin iframes, and even show time sequence / Stevens 
> graphs for message passing between promises in multiple JavaScript 
> contexts, when promises are used as proxies for remote objects through 
> a facility like Q-Connection
>
> https://github.com/kriskowal/q-connection
>
> Kris Kowal
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Received on Friday, 6 September 2013 02:59:24 UTC