New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Hash of Futures for Promises.zip #777
Comments
Forgot to mention that this pattern would apply to the errors section as well: # ...
Concurrent::Promises.zip(map_of_work).result
# => [true,
# {:multiply=>6,
# :divide=>1,
# :add=>5,
# :subtract=>1},
# {:multiply=>nil,
# :divide=>nil,
# :add=>nil,
# :subtract=>nil}] |
That is definitely an interesting idea, thanks for sharing! I'll leave it as |
Ok |
So I started working through a POC of this, trying to follow the documentation here for consistency as much as possible. Some notes:
I'll see about poking at it tomorrow, will post some code once I have a few good specs passing. |
@jamie remember
It's a gotcha that I've been bit by a few times.
|
Ah, that explains it. I was grepping the code for |
Thanks @jamie for looking into this. Please accept collaboration invitation, then I'll be able to assign the issue to you.
I am trying to think about how do this flexibly and without too much added complexity to the existing implementation. Something as follows could work { a: future { 1 },
b: future { 2 }
}.reduce(fulfilled_future({})) do |hf, (k, vf)|
(vf & hf).then { |v, h| h.update k => v }
end.value! #=> { a: 1, b: 2 } |
Reading the guide for the Promises work in 1.1.x I came across the fantastic
Concurrent::Promises.zip
method.It's interface, per the guide, expects an array of
Future
s and will return a final value of said array's values. This is beneficial, but what would make my (and I suspect many other's) code cleaner is to optionally accept aHash
of promises instead of anArray
.e.g.
Why? Because it's a common pattern in Javascript libraries[1][2], and thus my team.
Arrays are slightly more cumbersome where I have to remember that index 2 is always for the addition work. Should another developer prepend more
Future
s to the array, we must not forget to change all the indexes referenced thereafter. With hashes, an:add
is always an:add
.The text was updated successfully, but these errors were encountered: