Re: Promises: unhandled rejections and finally()

It does pass through the fulfillment status - but it does that by adding both an onFulfilled and an onRejected handler, so it does affect the "unhandled rejection" hook. On Sat, Mar 28, 2020 at 7:23 PM Felipe Gasper wrote: > Hi Logan, > > Thank you .. that makes sense. I’m not sure why now but

Re: Promises: unhandled rejections and finally()

Hi Logan, Thank you .. that makes sense. I’m not sure why now but I had in mind that finally() creates a “passthrough” promise that doesn’t affect its parent promise’s resolved/rejected status. Cheers, -Felipe > On Mar 28, 2020, at 21:40, Logan Smyth wrote: > >  > > Could someone point me

Re: Promises: unhandled rejections and finally()

> Could someone point me to something that would help me to understand the logic here? It looks like the first finally() is getting a “free pass” while only the 2nd and subsequent ones trigger their own unhandled-rejection warnings. I think the best place to start in understanding this would be

Re: Promises, async functions, and requestAnimationFrame, together.

Ah, I think the reason that this animation loop using promises works is because promise handlers resolve in the next microtask after the current macrotask. I believe that the animation frame fires in what is essentially a macrotask, then immediately after this macrotask the resolution of the

Re: Promises, async functions, and requestAnimationFrame, together.

This is definitely interesting stuff. Have you considered rewriting this so that it only uses generators? If you did then you could test natively in Chrome and see if you get the same results. - Matthew Robb On Sat, Apr 23, 2016 at 7:01 PM, /#!/JoePea wrote: > Just to show a

Re: Promises, async functions, and requestAnimationFrame

Note that there is no guarantee that the `then` handlers (after the await) will fire in the same loop since they defer execution on their own and might defer it further. In practice I assume they'll probe to see if they need to actually schedule asynchronously or the constructed promise is

Re: Promises, async functions, and requestAnimationFrame, together.

Just to show a little more detail, here's a screenshot that shows that the logic of the while-loop version of my animation loop fires inside each animation frame. I've zoomed out and we can see there's nothing fired between the frames:

Re: Promises, async functions, and requestAnimationFrame, together.

Alright, I did an experiment, and I'm really surprised at the results! Apparently, the logic (what would be drawSomething() in my previous example) is fired within the frame!! So, let me show you my original method for starting an animation loop. I'm working on a 3D project at http://infamous.io.

Re: Promises, async functions, and requestAnimationFrame, together.

On 4/23/16 4:09 AM, Salvador de la Puente González wrote: AFAIK, that should execute `drawSomething()` once per frame. Given a frame is each time the animatinFrame() promise resolves. What's not obvious to me is whether it will execute it before the actual paint for the frame (i.e. before or

Re: Promises, async functions, and requestAnimationFrame, together.

AFAIK, that should execute `drawSomething()` once per frame. Given a frame is each time the animatinFrame() promise resolves. On Sat, Apr 23, 2016 at 1:38 AM, /#!/JoePea wrote: > Is it possible? > > I thought maybe something like this: > > ```js > function animationFrame() { >

Re: Promises as Cancelation Tokens

*F# cancellation* - on second thought implicit cancellation through cancellation like in F# is impractical because of the eagerness of promises. I don't think it's a valid alternative here. I've discussed this with Reed Copsey (an F# expert) and he explained the philosophy behind it to me - it

Re: Promises as Cancelation Tokens

> > For async functions, it would mean that any await expression could > potentially throw a CancelError Cancellation does not necessarily need to use `throw`, `return` is often more apt. I find. I would also recommend splitting the idea of cancellation into: abort semantics, and ignorance

Re: Promises as Cancelation Tokens

Implicit cancellation doesn't make sense if it involves a throw. Furthermore, implicit cancellation would never happen for your example - the 'await' clearly depends on the result of the operation, so it is in use and it would not make sense for it to be implicitly cancelled. For the record, every

Re: Promises as Cancelation Tokens

> > I think F#'s cancellation approach is also worth mentioning in the > discussion of alternatives as it has implicit but token-based automatically > propagating cancellation. > If you have any good links to reference materials on F#'s cancellation architecture, feel free to include them for

Re: Promises as Cancelation Tokens

> Another cancellation scenario is when the consumer of an asynchronous task no longer > needs the result of an operation. In this case, they will only have access to the Promise > unless the cancellation token is routed to them through some other path. For what it's worth - this is exactly how

Re: Promises as Cancelation Tokens

One key thing to recognize is that there are different reasons to cancel an operation and as a result, different approaches to cancellation. .NET cancellation tokens address one scenario (and do it fairly well), where the objective is for specific operations to expose cancellation and allow the

Re: Promises as Cancelation Tokens

Thanks for posting this. Great stuff! > On a page that loads 100 images four at a time, you would want 4 cleanup > actions registered, not 100. > And in order to keep it to 4 you need a way to unregister the action when you complete the operation, which the promise API doesn't give you. I

Re: Promises as Cancelation Tokens

Thanks Ron! Comments inline... > · Once a callback has been registered for asynchronous notification > of a cancellation signal, it can later be unregistered. > Yes, I see how this could be helpful. > · Asynchronous notifications are queued and handled at a higher > priority than

Re: Promises as Cancelation Tokens

Since checking `promise.state` is synchronous, we may as well just write a synchronous Cancel class instead: ```js class CancelError extends Error { /* ... */ } class Cancel { constructor() { this.requested = false } request() { this.requested = true } throw() { throw new

Re: Promises as Cancelation Tokens

Cool, yeah, the reveal pattern would indeed be a good way to guard against unwanted/unexpected cancels. ```js class Cancel { constructor(executor) { this._requested = false executor(() => this._requested = true) } get requested() {return this._requested} throw() {

Re: Promises as Cancelation Tokens

> > Since checking `promise.state` is synchronous, we may as well just > write a synchronous Cancel class instead: > Right - see upthread. You do need some kind of callback method, though, like `whenCancelled(callback)`. > class Cancel { > constructor() { this.requested = false } >

Re: Promises as Cancelation Tokens

> > We have pretty sound cancellation semantics in bluebird 3. > Cool, I'm aware that cancellable promises have been explored in depth. I'd prefer to keep this thread focused on cancellation tokens though, and avoid comparisons. ___ es-discuss mailing

Re: Promises as Cancelation Tokens

> > The best approach in cases like this is to avoid the word altogether. > The fact that there's confusion at all means people will mess it up > and get annoyed, even if there's a "winner" in overall usage. > Hmmm... Maybe class CancelToken { constructor(init); get

Re: Promises as Cancelation Tokens

We have pretty sound cancellation semantics in bluebird 3. http://bluebirdjs.com/docs/api/cancellation.html Handles multiple subscribers soundly. Solves the common use cases pretty well - has absolutely zero magic and pretty simple semantics. They work with .all and .race too. We have had a

Re: Promises as Cancelation Tokens

> Cool, I'm aware that cancellable promises have been explored in depth. I'd prefer to keep this thread focused on cancellation tokens though, and avoid comparisons. Cool, re-reading the discussion you asked for this in the first message - I apologize for missing it. I think using promises as

Re: Promises as Cancelation Tokens

> We could use a promise subclass as the cancellation token, but then tokens (and their constructor) would inherit things that really don't make sense, like "CancelToken.resolve" and "CancelToken.prototype.catch". Generally I dislike inheritance. I was merely saying it's an option. I favor

Re: Promises as Cancelation Tokens

> > I think using promises as tokens would be problematic. It would have > several issues: > Agreed with all of those. It's also important to keep in mind that promises can be subclassed so it's > fine to add properties to them if used for a specific purpose like > cancellation. > We could use

RE: Promises as Cancelation Tokens

@domenic.me> Cc: es-discuss<mailto:es-discuss@mozilla.org> Subject: Re: Promises as Cancelation Tokens The best approach in cases like this is to avoid the word altogether. The fact that there's confusion at all means people will mess it up and get annoyed, even if there's a "winner"

Re: Promises as Cancelation Tokens

>From experience, I'm very much in favor of the cancellation token. Though promises provide a good inspiration for cancellation, they don't quite fit the problem directly. The approach has been explored, though the details are not published. I implemented cancellation for the Midori system.

Re: Promises as Cancelation Tokens

> throw() { throw new CancelError() } > This should be `throwIfRequested` I think, e.g. throwIfRequested() { if (this._requested) throw new CancelError(); } } > What would be the recommended way of keeping the internal state > private? With a WeakMap? >

Re: Promises as Cancelation Tokens

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 >

Re: Promises as Cancelation Tokens

> > 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) => {

Re: Promises as Cancelation Tokens

I agree that without synchronous inspection cancellation tokens become very hard to deal with as you may be queued for a long time prior to cancellation on the event loop, and then the operation is cancelled while you are waiting to check for cancellation. Is there a reason to use a Promise as the

Re: Promises as Cancelation Tokens

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

RE: Promises as Cancelation Tokens

In general I agree that there is a nice conceptual symmetry, but IMO the day-to-day impedance mismatch would be simply too great. Compare: ```js async function f(cancelationToken) { cancelationToken.then(() => console.log("FYI you have been canceled")); await

Re: Promises as Cancelation Tokens

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

RE: Promises as Cancelation Tokens

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

Re: Promises vs Streams

Domenic Denicola wrote: Seeing as how I just produced a completely redundant message by failing to read the other responses before firing off my own, let me try to redeem myself with some more-original content. (Nice post!) It’s also important to realize that streams are not the only

RE: Promises vs Streams

The same argument also implies that arrays are more powerful than scalar values, and we should e.g. never use a number when we could instead just use a single-element array with a number. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boopathi Rajaa Sent: Saturday, March

RE: Promises vs Streams

Seeing as how I just produced a completely redundant message by failing to read the other responses before firing off my own, let me try to redeem myself with some more-original content. It’s also important to realize that streams are not the only asynchronous-plural primitive out there. My

Re: Promises vs Streams

On Sat, Mar 28, 2015 at 1:14 PM, Boopathi Rajaa legend.r...@gmail.com 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

Re: Promises vs Streams

Synchronously, we have both normal (synchronous) function calls and iteration over a sequence of values (via `for-of` and iterators). It makes sense that we also should have two abstractions for asynchronous interaction. On 28 Mar 2015, at 13:14, Boopathi Rajaa legend.r...@gmail.com wrote:

Re: Promises vs Streams

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 in its

Re: Promises, the middle state : negociation

On Thu, May 15, 2014 at 11:33 AM, Michaël Rouges michael.rou...@gmail.com wrote: Hi all, As I totally agree that a promise can only be resolved or rejected once ... so I think his behavior is perhaps too black or white. As IRL, when we receive a promise, we expect that the author makes every

Re: Re: Promises, the middle state : negociation

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 illustrate the

Re: Re: Promises, the middle state : negociation

``` var sources = [internal, external1, external2]; function doStuff (e) { // likely check if it's the right kind of error; var url = sources.shift(); if (typeof url === 'undefined) { return Promise.reject(new Error('out of sources')); } return

Re: Promises and Decidability in Asynchronous Error Handling

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. I agree that an improved error handling policy would be very, very good to have, though. On Mon, Oct 21, 2013 at

RE: Promises and Decidability in Asynchronous Error Handling

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

Re: Promises and Decidability in Asynchronous Error Handling

wouldn't events better suit and better solve the problem ? fetchUri(http://someauthority.com/;).on('load', response = { repsonse.heders() }); at least this is how it works in eddy.js and I've never had silent errors in current specs would be an addEventListener() within the XHR object On

Re: Promises and Decidability in Asynchronous Error Handling

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*. { Kevin

Re: Promises and Decidability in Asynchronous Error Handling

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

RE: Promises and Decidability in Asynchronous Error Handling

I don't think that's the same thing at all. Detecting an infinite loop is _extremely_ hard at most cases (and of course impossible at others. However instead of discussing the halting problem, I think what's bothering this guy is that `.then` does not throw an error when an error occurs within it

RE: Promises and Decidability in Asynchronous Error Handling

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

Re: Promises and Decidability in Asynchronous Error Handling

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) {

RE: Promises and Decidability in Asynchronous Error Handling

+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()

Re: Promises and Decidability in Asynchronous Error Handling

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

Re: Promises: final steps

I have not read everything about the promise/future/re-promise subject but what I have read seems to show that everyone has a personal understanding of the thing. So please see http://lists.w3.org/Archives/Public/public-webcrypto/2013Sep/0003.html , code example that I have written for

Subject=Re: Re: Promises: final steps

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 an interesting avenue. The

RE: Subject=Re: Re: Promises: final steps

(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

Re: Promises: final steps

While I can agree that monitor feature (that's proposed instead of `done`) has some benefits, I see it only as an aid for developers that are inexperienced with promises, or as a fallback for those experienced. It looks more as a smart add-on, which to be complete can't be implemented in plain

Re: Promises: final steps

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

RE: Promises: final steps

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 choice at

Re: Promises: final steps

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 callback just

Re: Promises: final steps

On Thu, Sep 5, 2013 at 12:04 PM, Domenic Denicola dome...@domenicdenicola.com wrote: 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

Re: Promises: final steps

On Thu, Sep 5, 2013 at 1:21 PM, Kevin Smith zenpars...@gmail.com 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

RE: Promises: final steps

2:46 AM To: es-discuss@mozilla.org Subject: Re: Promises: final steps While I can agree that monitor feature (that's proposed instead of `done`) has some benefits, I see it only as an aid for developers that are inexperienced with promises, or as a fallback for those experienced

Re: Promises: final steps

This looks like good work. I like the name cast in particular, as I can imagine a future casting operator which provides sugar for the cast function defined on a constructor. The only concern I have is over error-swallowing. What's the approach for this minimal API? { Kevin }

Re: Promises: final steps

On Wed, Sep 4, 2013 at 7:34 AM, Kevin Smith zenpars...@gmail.com wrote: This looks like good work. I like the name cast in particular, as I can imagine a future casting operator which provides sugar for the cast function defined on a constructor. The only concern I have is over

Re: Promises: final steps

As far as I know, the current plan is still that devtools should handle swallowed exceptions, since we got rid of .done() some time ago. Plans may have changed without me knowing, though! ~TJ I'd be interested in more detail since I think this will be an important usability issue. Are any

Re: Promises: final steps

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

Re: Promises: final steps

On Tue, Sep 3, 2013 at 6:37 AM, Anne van Kesteren ann...@annevk.nl wrote: As many of you hopefully know, we're trying to nail down the design of promises in JavaScript so we can declare consensus on it and start shipping it in implementations. If you're interested in the particulars I strongly

RE: Promises Consensus

From: Mark S. Miller [erig...@google.com] No. Assuming that p and q are both promises and that q is pending, p is resolved to q when either p adopts q or p accepts q. From the .then perspective these are the same, so we'd say p follows q or p is resolved to q. In neither care would p.then

RE: Promises Consensus

Er, replace `notAcceptedAndNotResolved` with `resolvedButNotAccepted`. X_x ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Promises Consensus with /A+ terminology

On Fri, Aug 2, 2013 at 4:58 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 1, 2013 at 8:25 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Aug 1, 2013 at 11:27 AM, Mark S. Miller erig...@google.com wrote: For #2, since whatever DOM does quickly becomes a compat constraint on

Re: Promises Consensus

Le 1 août 2013 à 00:53, Claude Pache claude.pa...@gmail.com a écrit : Le 31 juil. 2013 à 20:23, Tab Atkins Jr. jackalm...@gmail.com a écrit : The first issue still up for community discussion involves the definition of promise-like. We'd like the definition to be: (a) a Promise or

Re: Promises Consensus with /A+ terminology

On Thu, Aug 1, 2013 at 8:25 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Aug 1, 2013 at 11:27 AM, Mark S. Miller erig...@google.com wrote: For #2, since whatever DOM does quickly becomes a compat constraint on all future decisions, DOM should take the minimum subset of #1 which

Re: Promises Consensus with /A+ terminology

Le 01/08/2013 20:27, Mark S. Miller a écrit : whatever DOM does quickly becomes a compat constraint on all future decisions (was the comma omitted on purpose? ;-) ) This also means that if there is a delta between the agreement and the implementation, we'll have yet another de facto standard.

Re: Promises Consensus with /A+ terminology

David Bruant wrote: I believe that to a large extent, the risk of both misunderstanding of intent and misexpression understood intent would be largely reduced by a test suite. +∞ /be ___ es-discuss mailing list es-discuss@mozilla.org

RE: Promises Consensus with /A+ terminology

From: Mark S. Miller [erig...@google.com] A good start would be to convert https://github.com/promises-aplus/promises-tests to test262 form, extending test262 in the process in order to accommodate async testing. Any volunteers? If someone does the latter (preferably with a simple

Re: Promises Consensus with /A+ terminology

On Fri, Aug 2, 2013 at 2:28 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Mark S. Miller [erig...@google.com] A good start would be to convert https://github.com/promises-aplus/promises-tests to test262 form, extending test262 in the process in order to accommodate async

Re: Promises Consensus with /A+ terminology

On Fri, Aug 2, 2013 at 2:42 PM, Mark Miller erig...@gmail.com wrote: On Fri, Aug 2, 2013 at 2:28 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Mark S. Miller [erig...@google.com] A good start would be to convert https://github.com/promises-aplus/promises-tests to test262

Re: Promises Consensus with /A+ terminology

On Thu, Aug 1, 2013 at 5:07 PM, Anne van Kesteren ann...@annevk.nl wrote: I basically took Tab's email and rewrote the terminology. I omitted the issues for brevity. Hopefully this helps. Having done that. I wonder if we could leave the monad part out for now. As Mark pointed out in the other

Re: Promises Consensus with /A+ terminology

On Thu, Aug 1, 2013 at 9:09 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 1, 2013 at 5:07 PM, Anne van Kesteren ann...@annevk.nl wrote: I basically took Tab's email and rewrote the terminology. I omitted the issues for brevity. Hopefully this helps. Sorry, I was waiting until Mark

Re: Promises Consensus

If then() deep flattens, flatMap() only flattens one level and promises assimilate thenables, is branding really necessary? Juan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Promises Consensus

On the input side of .then and .flatMap, no. On the output side of both .then and .flatMap, depending on what you mean by branding, yes. If .flatMap's callback returns a non-promise the promise it already returned gets rejected. If .then's callback returns a non-promise, the promise it already

Re: Promises Consensus

On Thu, Aug 1, 2013 at 10:33 AM, Juan Ignacio Dopazo dopazo.j...@gmail.com wrote: If then() deep flattens, flatMap() only flattens one level and promises assimilate thenables, is branding really necessary? The concept of thenable *is* branding. It's just branding with a short, simple string

Re: Promises Consensus

Between Tab's answer and mine, we see the two issues one might mean by branding. Anne's clarifying summary at https://mail.mozilla.org/pipermail/es-discuss/2013-August/032465.htmlspeaks only in terms of promise-likes. One of the things we need to settle is whether there is one predicate that

Re: Promises Consensus

On Thu, Aug 1, 2013 at 11:04 AM, Mark S. Miller erig...@google.com wrote: Between Tab's answer and mine, we see the two issues one might mean by branding. No, there's only the one concept. If you mean anything other than type detection via properties on the instance or its prototype chain, then

Re: Promises Consensus with /A+ terminology

On Thu, Aug 1, 2013 at 10:00 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Thu, Aug 1, 2013 at 9:09 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 1, 2013 at 5:07 PM, Anne van Kesteren ann...@annevk.nl wrote: I basically took Tab's email and rewrote the terminology. I omitted

Re: Promises Consensus

On Thu, Aug 1, 2013 at 11:26 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Thu, Aug 1, 2013 at 11:04 AM, Mark S. Miller erig...@google.com wrote: Between Tab's answer and mine, we see the two issues one might mean by branding. No, there's only the one concept. If you mean anything

Re: Promises Consensus with /A+ terminology

On Thu, Aug 1, 2013 at 11:27 AM, Mark S. Miller erig...@google.com wrote: There are three questions here, which need to be settled in roughly this chronological order: 1) What should tc39 do quickly, to unblock the DOM's need for promises and avoid a design fork? 2) What should DOM do quickly

RE: Promises Consensus

Just some terminology questions for this new proposal... From: Tab Atkins Jr. [jackalm...@gmail.com] whatever p resolves to, gets passed to the flatMap() callbacks. What does resolves mean in this context? I don't believe you are using it in the same way that it is used in Promises/A+ or DOM

Re: Promises Consensus

[Gah, resending because I'm being *way* too loose with my terminology. Ignore previous email - this one has identical content, but uses terms correctly.] (Scratch that, I added a new point #3 at the end of the email.) [For the purposes of this email, a promise accepting or rejecting means that

RE: Promises Consensus

From: Tab Atkins Jr. [jackalm...@gmail.com] For the purposes of this email, a promise accepting or rejecting means that its resolver's accept() or reject() method was called, or the equivalent internal magic. fulfill means accept or reject. resolve means adopt or accept, depending on

Re: Promises Consensus

On Wed, Jul 31, 2013 at 11:38 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Tab Atkins Jr. [jackalm...@gmail.com] For the purposes of this email, a promise accepting or rejecting means that its resolver's accept() or reject() method was called, or the equivalent internal

Re: Promises Consensus

Does this all mean that you're ok with having promises-for-promises? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Promises Consensus

On Wed, Jul 31, 2013 at 12:48 PM, Juan Ignacio Dopazo dopazo.j...@gmail.com wrote: Does this all mean that you're ok with having promises-for-promises? I've always been okay with that. ^_^ This consensus details how to handle nested promises (use .flatMap()) *and* how to ignore that and just

RE: Promises Consensus

From: Mark S. Miller [erig...@google.com] One thing I think Domenic is missing that I also missed at first: Once we introduce .flatMap, then we need a distinct accepted state that is neither fulfilled nor rejected. The issue is that p.then does not fire until the promise p is fulfilled or

Re: Promises Consensus

Le 31 juil. 2013 à 20:23, Tab Atkins Jr. jackalm...@gmail.com a écrit : The first issue still up for community discussion involves the definition of promise-like. We'd like the definition to be: (a) a Promise or subtype, or (b) a branded non-Promise (with the branding done via Symbol or

Re: Promises Consensus

On Wed, Jul 31, 2013 at 3:52 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Mark S. Miller [erig...@google.com] One thing I think Domenic is missing that I also missed at first: Once we introduce .flatMap, then we need a distinct accepted state that is neither fulfilled nor

  1   2   >