You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1 resolved
triple resolved (500ms later)
double resolved (1500ms after that)
1 (all at once)
2 (^)
3 (^)
However the current behaviour assumes all promises exist as 'chains' with no branches. This also causes 'waterfall' behaviour with its execution.
1 resolved
double resolved (2000ms later)
triple resolved (500ms after that)
6 (all at once)
6 (^)
6 (^)
I assume the former would actually be the intended behaviour for the library given the comments for the Then function:
// Appends fulfillment to the promise,
// and returns a new promise.
The Then function distinctly does not return a new promise, it returns the same promise, adding the fulfilment function to the list.
The fix is relatively simple, copy the Promise every time the Then function is called to branch it off, actually returning a new Promise.
The Catch function should not return a new promise, but the old promise, it should not copy it.
Essentially this:
// Then appends a fulfillment handler to the Promise, and returns a new promise.func (promise*Promise) Then(fulfillmentfunc(datainterface{}) interface{}) *Promise {
promise.mutex.Lock()
deferpromise.mutex.Unlock()
promiseCopy:=promise.copy()
switchpromiseCopy.state {
casepending:
promiseCopy.wg.Add(1)
promiseCopy.then=append(promiseCopy.then, fulfillment)
casefulfilled:
promiseCopy.result=fulfillment(promiseCopy.result)
}
returnpromiseCopy
}
// copy creates a copy of a Promise that resolves when it does, it returns the new Promise.func (promise*Promise) copy() *Promise {
p:=New(func(resolvefunc(interface{}), rejectfunc(error)) {
data, err:=promise.Await()
iferr!=nil {
reject(err)
return
}
resolve(data)
})
returnp
}
This obviously changes the behaviour of the library in a breaking manner.
Would a PR like this be accepted? I would assume a major version bump to v2 would have to be done?
Alternatively I can just create a fork with the different behaviour.
What are your thoughts?
Thanks.
The text was updated successfully, but these errors were encountered:
I did a quick test to confirm this behaviour in JS
I agree that we should follow the same behaviour as JS since it's an actual feature that can be used by users.
In terms of breaking and versioning - initially I planned v2 as a release where we finally adopt Go's Generics which, in my opinion, is more of a breaking change than correcting existing behaviour.
Let me know if you want to go ahead and implement a fix for this.
Hello,
One of the powerful features of Promises in a JS context is the ability to 'branch' the 'then' functions.
One promise can provide data to multiple other promises that do independent things with it.
In Go, take this example code:
The expected behaviour would be for it to print:
However the current behaviour assumes all promises exist as 'chains' with no branches. This also causes 'waterfall' behaviour with its execution.
I assume the former would actually be the intended behaviour for the library given the comments for the
Then
function:The
Then
function distinctly does not return a new promise, it returns the same promise, adding the fulfilment function to the list.The fix is relatively simple, copy the Promise every time the
Then
function is called to branch it off, actually returning a new Promise.The
Catch
function should not return a new promise, but the old promise, it should not copy it.Essentially this:
This obviously changes the behaviour of the library in a breaking manner.
Would a PR like this be accepted? I would assume a major version bump to v2 would have to be done?
Alternatively I can just create a fork with the different behaviour.
What are your thoughts?
Thanks.
The text was updated successfully, but these errors were encountered: