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
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
19 matches
Mail list logo
