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 promises could
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 races with cancellation
and
Note that when you attach a reaction (through the `.then()` method) to a
promise that was resolved several minutes ago, the reaction will trigger: you
have to somewhat stretch you mind in order to call that reacting to state
change.
What attaching callbacks through `.then()` really does is
Am I the only one that sees this concept best left as a user Promise
subclass? Especially since I'm still seeing some disagreement on even what
the problem is that's needing solved.
On Sat, Aug 8, 2015, 05:02 Glen Huang curvedm...@gmail.com wrote:
Note that when you attach a reaction (through
Le 6 août 2015 à 04:20, Glen Huang curvedm...@gmail.com 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 proposing to add is no
Given your example of
```
let done = query.done;
done.then(updateView).then(log, logAbort);
done.ignore(updateView);
```
The core of my complaint comes down to control flow. To demonstrate, let's
convert this to a co generator so it's readable like sync code.
```
co(function*(){
try {
let
like I've said ...
On Wed, Aug 5, 2015 at 1:32 AM, Glen Huang curvedm...@gmail.com wrote:
What do you think of the ignore() method I proposed?
... I don't want to express myself further.
I think this story should be split in few little stories. The first one
would be asking around how many
What you are asking for seems like a way to halt execution of the function,
without ever returning from the function, or executing either branch of the
try/catch
This also happens when query.done never resolves / rejects. You don't need to
introduce ignore() to trigger this behavior.
I
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 the callbacks.
Glen, sorry if this has been covered in other discussions, but it's not
clear to me so I wanted to ask. Are there some example use-cases where
being able to `.ignore` is preferable to having the promise reject? Promise
chains are about defining flows of data and I can't really see a case where
On Aug 4, 2015, at 1:32 PM, Andrea Giammarchi andrea.giammar...@gmail.com
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
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 promise
@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 to accidentally have the
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 promises were specced
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
undefined for
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
passed through their initialization
I have thought about something similar before, and used it in one of my
libs. Recently, I have come up another idea, it was already implemented on
Yaku:
let Promise = require('yaku')
// The `self` is the instance of the newly created promise.let p = new
Promise((resolve, reject, self) = {
let
not so different from what I've proposed already, except it looks ugly with
a `self` at the end, and it's based on runtime method attachment that could
happen at any time or mislead, or forget to invoke reject etc etc ... I
will try to stay away from this thread 'cause I've already talked as much
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
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 is a great
From: Andrea Giammarchi andrea.giammar...@gmail.com
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:
...@gmail.com
Sent: 2/27/2015 8:01 PM
To: Andrea Giammarchi andrea.giammar...@gmail.com
Cc: public-script-co...@w3.org; es-discuss es-discuss@mozilla.org
Subject: Re: Cancelable promises
On Fri, Feb 27, 2015 at 7:49 PM, John Lenz concavel...@gmail.com wrote:
Closure Library's promise
: Cancelable promises
On Fri, Feb 27, 2015 at 7:49 PM, John Lenz
concavel...@gmail.commailto:concavel...@gmail.com 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
On Fri, Feb 27, 2015 at 7:49 PM, John Lenz concavel...@gmail.com 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 child promises are also
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
AsyncJS (http://github.com/rbuckton/asyncjs) uses a separate abstraction
for cancellation based on the .NET
CancellationTokenSource/CancellationToken types. You can find more
information about this abstraction in the MSDN documentation here:
On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi
andrea.giammar...@gmail.com 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 wins
Re fetch: https://github.com/whatwg/fetch/issues/20
On Fri, 27 Feb 2015 23:08 Jonas Sicking jo...@sicking.cc wrote:
On Thu, Feb 26, 2015 at 11:43 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
AFAIK bluebird did:
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 way to
The discussion on that github issue surrounding promise subclassing makes
my head spin, especially when it comes to working out how cancelation is
supposed to flow through a graph of promise dependencies. We should be
wary of adding complexity to the core.
The simple way to view the situation is
30 matches
Mail list logo
