On Mon, Jan 4, 2016 at 9:01 AM, Domenic Denicola wrote:
> From: Kevin Smith [mailto:zenpars...@gmail.com]
>
>> And what's the deal, is it canceled or cancelled? : )
>
> This is kind of the worst. Previous discussion at
> https://github.com/promises-aplus/cancellati
>
> I am also unsure when .whenCanceled is necessary
>
Maybe in the case where you have a promise-returning function and you want
to reject the returned promise upon cancellation.
function delayWithCancel(ms, cancelToken) {
return new Promise((resolve, reject) => {
setTimeout(re
From: Kevin Smith [mailto:zenpars...@gmail.com]
> And what's the deal, is it canceled or cancelled? : )
This is kind of the worst. Previous discussion at
https://github.com/promises-aplus/cancellation-spec/issues/4.
Data seems to favor cancelled:
-
https://books.google.com/ngra
And what's the deal, is it canceled or cancelled? : )
On Mon, Jan 4, 2016 at 11:30 AM Kevin Smith wrote:
> Is there a reason to use a Promise as the cancellation token, rather than
>> have something that is synchronously inspectable?
>>
>
> The only real downside of coming up with a new interf
>
> Is there a reason to use a Promise as the cancellation token, rather than
> have something that is synchronously inspectable?
>
The only real downside of coming up with a new interface is that we have to
standardize it. : ) It's a core protocol.
I agree that using a promise directly would f
cancellation token, rather than have something that is
synchronously inspectable? Even a small class/interface like:
```javascript
let cancelled = false;
myPromise.then(() => cancelled = true);
task[Symbol.cancelled] = () => cancelled;
```
For this reason I do not think Promises are the
e rejection path is not necessary.
So, if cancelation tokens are the right path, I'd prefer not reusing promises
for them. Maybe it argues for easily being able to create a cancelation token
from a promise, though.
Semi-related: I was recently reading
http://joeduffyblog.com/2015/11/19/as
I'm interested in exploring the idea of using an approach similar to .NET's
cancelation tokens in JS for async task cancelation. Since the cancelation
"flag" is effectively an eventual value, it seems like promises are
well-suited to modeling the token. Using a promise for
IMO promises should reject if they are "cancelled". The same method that
gave you the Promise (for example, an AJAX API) can give you a capability
to "cancel" the Promise, ie cancel the pending network operation and reject
the Promise (rejecting is a no-op if the operation rac
On 8/3/15 8:15 PM, Glen Huang wrote:
Ideally, if the same resolve & reject callback combination is passed more than
once, the same promise is always returned
That's a backwards-incompatible change from what browsers are shipping,
right?
(I can't think of a use case where
say that, from the
> reaction's point of view, the parent promise's state has changed.
>
> As I understand, promises are ideal for requesting and transmitting data
> without having to care much when the data is available
>
>
> IMHO, that's promises's goa
promise, I think it's reasonable to say that, from the
reaction's point of view, the parent promise's state has changed.
> As I understand, promises are ideal for requesting and transmitting data
> without having to care much when the data is available
IMHO, that's promises&
> Le 6 août 2015 à 04:20, Glen Huang a écrit :
>
>> promises are fundamentally about chaining data together, not about listening
>> for events.
>
> IMHO, promises are more about reacting to state change and pass down that
> reaction. And the reaction I'm propo
s behavior.
I think .ignore() is more similar to
```
let timer = setTimeout(...);
clearTimeout(timer);
```
Trying to imagine setTimeout as a promise that never rejects.
> promises are fundamentally about chaining data together, not about listening
> for events.
IMHO, promises are more abo
ow many here thinks Promises should be cancelable
in first place.
There's no equivalent like a silent failure in a synchronous like
await/generator world and since promises are apparently used as de-facto
pattern too deal with that, you'll find hard time to resolve this problem.
Once this
try/catch. In synchronous code the only way to achieve this would be
`while(true){}`, which is terrible. There isn't really a world where I'd
expect that code to execute neither side, because promises are
fundamentally about chaining data together, not about listening for events.
Instead
> Are there some example use-cases where being able to `.ignore` is preferable
> to having the promise reject?
The purpose of .ignore() is to let promises show disinterest, by disinterest, i
mean the situation that whatever happens to that promise, it shouldn't be
observable to th
case where
you'd want to disconnect a promise handler without informing promises
farther down the chain, like your `.then(log)` in your example. To me
anyway, the proposed `.ignore` seems like it adds boat-loads of complexity
with unclear goals.
Also to your question about adding multiple ha
> On Aug 4, 2015, at 1:32 PM, Andrea Giammarchi
> wrote:
>
> only promises that has passed through their initialization the callback would
> be cancelable,and this could be reflected through a `.cancelable` property
That's precisely the problem. When you made a mistake an
> if used when cancelable is true
if used when cancelable is NOT true, so throw if non cancelable
On Tue, Aug 4, 2015 at 6:32 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> my proposal doesn't make abortability accidental, only promises that has
>
my proposal doesn't make abortability accidental, only promises that has
passed through their initialization the callback would be cancelable,and
this could be reflected through a `.cancelable` property. We could have
`.abort()` throwing if used when cancelable is true ( or not
undefine
@Andrea @Yad
The only thing I'm not sure about is this "some promises have the abort
ability, some don't" design. It might seem clear when you first create that
promise, but it gets messy when you start to pass that promise around. It's
very easy for some function
This is a good point. I didn't think about passing the same callback more than
once.
Ideally, if the same resolve & reject callback combination is passed more than
once, the same promise is always returned (I can't think of a use case where
promises could stop to work, if promise
t; {
> clearTimeout(tmr)
> reject(new Error('abort promise'))
> }
>
> })
>
> p.abort()
>
> The origin post is here:
> https://github.com/promises-aplus/cancellation-spec/issues/16.
>
> what do you think about it?
>
> 2015年8月3日(月) 8:4
On 8/2/15 8:43 PM, Glen Huang wrote:
You can think it as that each promise keeps a list of its child promises, when
the same callback is passed to .ignore() it sets a flag on the corresponding
child promise so that when itself resolves/rejects, it won't pass that state to
that child pr
ject, self) => {
let tmr = setTimeout(resolve, 3000)
let self.abort = () => {
clearTimeout(tmr)
reject(new Error('abort promise'))
}
})
p.abort()
The origin post is here:
https://github.com/promises-aplus/cancellation-spec/issues/16.
what do you think about i
I was discussing with Jake Archibald about cancelable promises the other day. I
was trying to convince him promise.cancel() might not be a good idea. But that
conversation unfortunately leans more towards on how the abort API should be
exposed on fetch. I did provide some thoughts on that topic
And --- apologies for continuing to beat this drum --- you can look at the
`prfun` package on npm for a practical example of this use of Promise
subclasses and `resolve`.
If other folks know of other libraries using these features, let me know so
I can recommend other people's code as well as my o
Awesome, thank you!
-N
On 7/14/2015 10:12 AM, Domenic Denicola wrote:
Yes.
On Tue, Jul 14, 2015 at 10:10 AM -0700, "Nicholas C. Zakas"
mailto:standa...@nczconsulting.com>> wrote:
Hi all,
I'm trying to wrap my head around derived promises and wanted to ask for
a
Yes.
On Tue, Jul 14, 2015 at 10:10 AM -0700, "Nicholas C. Zakas"
mailto:standa...@nczconsulting.com>> wrote:
Hi all,
I'm trying to wrap my head around derived promises and wanted to ask for
a bit of clarification around how `Promise.resolve()` works from a
derived
Hi all,
I'm trying to wrap my head around derived promises and wanted to ask for
a bit of clarification around how `Promise.resolve()` works from a
derived class. Consider this:
```
class MyPromise extends Promise {}
var p1 = new Promise(function(resolve, reject) {
resolve(42);
});
Thanks for the explanation guys. Looking forward to see both of
cancellation and finally in ECMAScript 2016! :) (as well as async/await)...
On an unrelated note, does anyone know if any of Firefox, Edge, and
Safari/WebKit have plans to implement the full ECMAScript 2015 by the end
of 2015?
On Sun
You can get `Promise #finally` by using a helper library, like `prfun`.
But the finally method in particular has a quirk, see the end of:
https://github.com/cscott/prfun/blob/master/README.md#promisefinallyfunction-handler--promise
It would be nice to resolve that properly before standardization.
The reason ECMAScript 2015 promises do not have `finally` is because it
wasn't necessary for the initial proposal and things were 'running late'
already and it was possible to ship without it. Shipping fast enabled us to
include promises in ECMAScript 2015.
It is entirely possible
Hi all,
I was just wondering why `finally` didn't make it into the ECMAScript 2015
spec's Promises?
They seem to me to be necessary for many use cases.
--
Best regards,
Behrang Saeedzadeh
___
es-discuss mailing list
es-discuss@mozilla
Hi folks
I have been fidingly with ES6 for over a year now, but for even longer I have
been longing for a more expressive and honestly simpler build system /
automation tool. I have dabbled with gulp, grunt and brunch and while they do
get the job done and are great in their own way, I feel the
so nice to be able to build one on top of the other, in the way
streams are built on top of promises!
[gtor]: https://github.com/kriskowal/gtor/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_
urity invariants to simply being able to reason about the flow of your code.
And it's also nice to be able to build one on top of the other, in the way
streams are built on top of promises!
[gtor]: https://github.com/kriskowal/gtor/
___
es-discuss
28, 2015 08:15
To: es-discuss@mozilla.org
Subject: Promises vs Streams
I feel this must have already been discussed but couldn't find any discussion
threads, just trying to understand them better.
The basic doubt is that I feel promises are more like streams, and that streams
are much
this must have already been discussed but couldn't find any discussion
> threads, just trying to understand them better.
>
> The basic doubt is that I feel promises are more like streams, and that
> streams are much more powerful than promises. With a promise you have a value
>
Maybe the confusion stems from how Promises were used in ES5? ES5 doesn't
support generators, so people ended up adding a sort of psuedo-generator
API to their promise APIs, but in reality the concepts solve different
problems? FYI, python seems to use promises and event streams together i
On Sat, Mar 28, 2015 at 1:14 PM, Boopathi Rajaa wrote:
> Why do we have both?
Why do we have both values and arrays, not just the latter?
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listi
I feel this must have already been discussed but couldn't find any
discussion threads, just trying to understand them better.
The basic doubt is that I feel promises are more like streams, and that
streams are much more powerful than promises. With a promise you have a
value or an exception
>
>
> > So again the question is: can we come up with a cancellation-token-style
> pattern which is JS-ergonomic?
>
> I tried to discuss some stuff in that direction at
> https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75342617
>
>
I think using a promise in place of a "token i
From: Kevin Smith [mailto:zenpars...@gmail.com]
> So again the question is: can we come up with a cancellation-token-style
> pattern which is JS-ergonomic?
I tried to discuss some stuff in that direction at
https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75342617
>
>
> That design seems far cleaner than adding functionality directly to
> promises, but can it be made JS-ergonomic?
>
>
The question we need to consider when it comes to a general design for
canceling async tasks is this: how does one offer cancellation when
defining an a
> From: Andrea Giammarchi
> AFAIK bluebird did:
> https://github.com/petkaantonov/bluebird
/blob/master/API.md#cancelerror-reason---promise
For what it's worth - bluebird is swapping its cancellation implementation
in a week or two. You can read about it here:
https://github.com/petkaantonov/blue
it
likes (or not at all).
That design seems far cleaner than adding functionality directly to
promises, but can it be made JS-ergonomic?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
What is cancelable is the value of the fetch() promise, not the fetch
itself. Extending the promise API is extending the concept of control flow
and I think this require a separated discussion. To make fetch() to be
cancelable should not affect promises at all.
TL;DR; I think the cancelable
gt; Ron
> --
> From: John Lenz
> Sent: 2/27/2015 8:01 PM
> To: Andrea Giammarchi
> Cc: public-script-co...@w3.org; es-discuss
> Subject: Re: Cancelable promises
>
>
>
> On Fri, Feb 27, 2015 at 7:49 PM, John Lenz wrote:
>
>> C
@mozilla.org>
Subject: Re: Cancelable promises
On Fri, Feb 27, 2015 at 7:49 PM, John Lenz
mailto:concavel...@gmail.com>> wrote:
Closure Library's promise implementation supports "cancel":
https://github.com/google/closure-library/blob/master/closure/goog/promise/promise.js
On Fri, Feb 27, 2015 at 7:49 PM, John Lenz wrote:
> Closure Library's promise implementation supports "cancel":
>
>
> https://github.com/google/closure-library/blob/master/closure/goog/promise/promise.js#L502
>
> A promise is cancelled only if all the "ch
Closure Library's promise implementation supports "cancel":
https://github.com/google/closure-library/blob/master/closure/goog/promise/promise.js#L502
A promise is cancelled only if all the "child" promises are also cancelled.
On Thu, Feb 26, 2015 at 11:43 PM, Andrea Gi
--promise
> >
> > But I agree once you've made Promises more complex than events ( xhr in
> this
> > case ) nobody wins :-/
> >
> > Although, specially for fetch or anything network related, there
> **must** be
> > a way to bloody cancel that!
> >
On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi
wrote:
> AFAIK bluebird did:
> https://github.com/petkaantonov/bluebird/blob/master/API.md#cancelerror-reason---promise
>
> But I agree once you've made Promises more complex than events ( xhr in this
> case ) nobody w
AFAIK bluebird did:
https://github.com/petkaantonov/bluebird/blob/master/API.md#cancelerror-reason---promise
But I agree once you've made Promises more complex than events ( xhr in
this case ) nobody wins :-/
Although, specially for fetch or anything network related, there **must**
be a w
to say that promises are simply
transparent containers for asynchronous values. Control capabilities should
therefore be represented by a separate abstraction. This will help keep
complexity at the edges.
Has any library experimented with the cancelation token approach yet?
On Feb 27, 2015 1:46 AM
As a heads up, there's some debate around the fetch() API how exactly
request termination should work and how that affects promises:
https://github.com/slightlyoff/ServiceWorker/issues/625
The WebRTC WG has also been discussing canceling in the context of
terminating a request for permi
-improvements (long, but talks
> about a couple potential/proposed solutions)
>
> -Jeff
>
>
> On 1/13/15 7:44 AM, Marius Gundersen wrote:
>
> A `promise.done()` method that throws if it receives a rejected promise
> has been discussed, but the consensus seems to be t
15 7:44 AM, Marius Gundersen wrote:
A `promise.done()` method that throws if it receives a rejected
promise has been discussed, but the consensus seems to be that
browsers instead should report on rejected unhandled promises that are
garbage collected. This is already implemented in Firefox (a
A `promise.done()` method that throws if it receives a rejected promise has
been discussed, but the consensus seems to be that browsers instead should
report on rejected unhandled promises that are garbage collected. This is
already implemented in Firefox (at least in the DevTools edition), where
```
Promise
.resolve()
.then(function(){
throw new Error('asdf');
});
```
Bluebird: (errors thrown - Good)
http://jsbin.com/kahuzi/1/edit?html,js,console
native ES6:(errors not thrown)
http://jsbin.com/qivobibowa/3/edit?html,js,console
Shouldn't all Uncaught errors be thrown, instead o
Figured it out: This is needed for “locking in”.
Quoting [1]:
> A promise is _resolved_ if it is settled or if it has been "locked in" to
> match the state of another promise. Attempting to resolve or reject a
> resolved promise has no effect.
[1] https://people.mozilla.org/~jorendorff/es6-dra
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createresolvingfunctions
Each resolving function R uses R.[[AlreadyResolved]].[[value]] to prevent the
same promise from being resolved twice.
Question: Couldn’t R.[[Promise]].[[PromiseState]] be used, instead?
--
Dr. Axel Rauschmayer
a
FYI, I've started working out how structured cloning could work for promises:
https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/6
This is part of a larger initiative to figure out the story for both structured
cloning and tranferability for both promises and the upcom
l).then(check).catch(doStuff);
}
```
On Thu, May 15, 2014 at 10:52 AM, Michaël Rouges
wrote:
> I don't pretend that impossible to do with current promises.
>
> I'm just saying that we can get a complexity that could be easily avoided.
>
> And a catch/then doesn't allow to
I don't pretend that impossible to do with current promises.
I'm just saying that we can get a complexity that could be easily avoided.
And a catch/then doesn't allow to return in the first promise onFulfilled,
without embedded promises.
I think a practical example might better
every
> effort to resolve it, by any way.
>
> Progammatically, we can wish the same.
>
> By example, we can have :
>
> an error to ignore
> an error that requires to execute other operations leading to
>
> a rejection
> a continuation
> a retry
>
> To cover al
example, we can have :
- an error to ignore
- an error that requires to execute other operations leading to
- a rejection
- a continuation
- a retry
To cover all these cases, in the current promises state, we can have (a
quite) complex promises, easily solvable.
My idea? the
It has been shown that delayed registration, in general, is useful.
However, it has not been demonstrated that delayed registration of a
primary error handler is necessary.
If use cases have been provided, then please provide links. Otherwise,
let's not use ad hominem in place of logic.
{ Kevin
+1
Nathan
Domenic Denicola wrote:
> A well-known problem with loops, as implemented in various programming
> languages, is that infinite loops are silenced by default. Consider the
> following program, which simply adds some numbers in a loop:
>
> ```js
> var sum = 0;
> while (Math.random() <
Kevin I have no idea which library you are using but if you do this:
```
fetchUri("http://someauthority.com/";).then(response => {
for (let header of repsonse.heders) // Note the misspelling!
console.log(header.key, header.value);
}).then(Object, function error(e) {
You have been given examples in several previous conversations, but have chosen
to not find them convincing. I (and others) tire of rehashing this argument
with you monthly.
I instead responded to the novel content of your post, which was some sort of
attempt to claim that a language feature al
ccurs within it even if that error is completely unhandled
by the promise flow.
Different libraries that implement promises handle errors differently. For
example bluebird[0] writes the stack trace to stderr (or console.error) if
the rejection is unhandled by the start of the second turn. I quo
Domenic,
First, your caricature of my position is patently ridiculous.
Second, can you or someone else offer a clear use case which requires
undecidable error handling semantics? I have asked for examples several
times and so far I haven't seen anything convincing. Usually that
indicates that t
From: Domenic Denicola [dome...@domenicdenicola.com]
> which should cause the program to report an infinite loop as the condition
> will never be true.
On the other hand, sometimes we forget how loops work entirely in a moment of
CSS-induced amnesia, and feel dumb on public mailing lists. Um, t
> Requiring early registration prevents the use of futures as value
> containers; i.e. kicking off an operation and storing the Future somewhere
> so anyone can use it at a later date.
>
One can always do that, provided that you register an error handler *before
your call stack is cleared*.
{ Kev
A well-known problem with loops, as implemented in various programming
languages, is that infinite loops are silenced by default. Consider the
following program, which simply adds some numbers in a loop:
```js
var sum = 0;
while (Math.random() < config.loopLimt) { // Note the misspelling!
sum
an improved error handling policy would be very, very good to
> have, though.
>
>
> On Mon, Oct 21, 2013 at 9:40 AM, Kevin Smith wrote:
>
>> A well-known problem with Promises, as implemented in various Javascript
>> libraries, is that program errors are silenced by defa
:40 AM, Kevin Smith wrote:
> A well-known problem with Promises, as implemented in various Javascript
> libraries, is that program errors are silenced by default. Consider the
> following program, which simply makes an HTTP request and then prints out
> the HTTP response headers:
>
A well-known problem with Promises, as implemented in various Javascript
libraries, is that program errors are silenced by default. Consider the
following program, which simply makes an HTTP request and then prints out
the HTTP response headers:
fetchUri("http://someauthority.com/&qu
At <http://flippinawesome.org/2013/10/14/a-simple-visual-model-for-promises/>.
I enjoyed it.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Oct 4, 2013 at 3:39 AM, Brendan Eich wrote:
> Yusuke SUZUKI wrote:
>
>> Make sense. So microtasks won't be introduced yet, but Promises and
>> asynchronous execution semantics (enough for Promises) are introduced into
>> ES6. Is it correct?
>>
>
&g
Yes. The only immediate correctness constraint needed in ES6 and the
immediate DOM timeframe is the "empty stack" requirement
Stated at <
https://github.com/domenic/promises-unwrapping#coercethenablethenable-then>
as
"4. Assert: the execution context stack is empt
Yusuke SUZUKI wrote:
Make sense. So microtasks won't be introduced yet, but Promises and
asynchronous execution semantics (enough for Promises) are introduced
into ES6. Is it correct?
And enough for modules.
And really, as dherman points out, the event loop and shared state
concurrency
loop itself
> into the language. The only requirement is that promises are async WRT the
> calling code. Delivery at the end of the current turn is allowed.
> Object.observe will require that we define an order, but until then, hand
> waving is sufficient.
>
Make sense. So microtasks won&
On 3 Oct 2013 08:23, "Yusuke SUZUKI" wrote:
>
> Hi,
>
> I'm very interested in implementing Promises and integrating it to
ECMAScript engine (e.g. V8, SpiderMonkey, JSC)
>
> Last night, I saw the meeting notes of Sep TC39 meetings carefully and I
was very surpri
Hi,
I'm very interested in implementing Promises and integrating it to
ECMAScript engine (e.g. V8, SpiderMonkey, JSC)
Last night, I saw the meeting notes of Sep TC39 meetings carefully and I
was very surprised that it is said that Promises will be introduced into
ES6.
It refers the micro
(but usually does).
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
e...@evan-borden.com
Sent: Sunday, September 8, 2013 20:25
To: To=; es-discuss@mozilla.org
Subject: Subject=Re: Re: Promises: final steps
Tasks in C# throw the recorded exception when the Task is finalized by
> Tasks in C# throw the recorded exception when the Task is finalized by the
> GC if it hasn't been handled by user code, though I don't know if something
> similar could be supported for ES7 Promises nor whether or not that makes
> sense for ES7 promises either.
This is
WebCrypto (ie real working case not
using WebCrypto rewritten with WebCrypto promises), as explained I am
using 'done' despite of the fact that it might be removed, because I
don't see why I should use 'then' if I am not chaining anything.
As explained again, the example
(Added back the other lists.)
On Fri, Sep 6, 2013 at 3:58 AM, Brendan Eich wrote:
> Let's put done back in. It's the right thing.
Given what has been said thus far
https://github.com/domenic/promises-unwrapping/issues/19 my
inclination is still to leave it out initially and g
> Please do.
>
You're not going to like it, which will explain my hesitation : )
Think of all promises as existing in a forest, where "root" promises are
created using the Promise constructor and "child" promises are created
using `then`. Promises with [[Value]
On Thu, Sep 5, 2013 at 10:32 AM, Ron Buckton wrote:
> Tasks in C# throw the recorded exception when the Task is finalized by the
> GC if it hasn't been handled by user code, though I don't know if something
> similar could be supported for ES7 Promises nor whether or not tha
Tasks in C# throw the recorded exception when the Task is finalized by the GC
if it hasn't been handled by user code, though I don't know if something
similar could be supported for ES7 Promises nor whether or not that makes sense
for ES7 promises either.
Having Promise rejections
On Thu, Sep 5, 2013 at 1:21 PM, Kevin Smith wrote:
>
> It's not clear to me why this, or your `Promise.throw`, is better than
>>
>> ```js
>> somePromise.done(...)
>> // or
>> somePromise.then(...).done()
>> ```
>
>
> Not *much* better, I'd say, but IMO a `done` method which accepts a
> callback o
isional 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.
>
Tha
> It's not clear to me why this, or your `Promise.throw`, is better than
>
> ```js
> somePromise.done(...)
> // or
> somePromise.then(...).done()
> ```
Not *much* better, I'd say, but IMO a `done` method which accepts a
callback overlaps too much with `then`, and a `done` method without a
callbac
From: Kevin Smith [zenpars...@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 cho
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
em
101 - 200 of 371 matches
Mail list logo
