Previously, Future.withEventualValue() tried to match the Future constructor, with one subtle difference in behavior. It interpreted null to mean "run the function again," which causes an infinite loop if the programmer returns null without realizing. Joshua found a regression of this sort in Lime itself, one I should have caught but overlooked.
This PR changes the function signature to avoid any possibility of this error. There is no return value anymore, so you can't accidentally return the wrong value. Instead, as with ThreadPool, you are given a WorkOutput object and must call sendComplete() at some point. The work function has the same signature as in ThreadPool, so if users understand the one, they'll understand the other.
I have a couple other branches that are closer to how withEventualValue() used to work, and I can bring them back if requested. But withEventualValue() is new in 8.2.0, so it shouldn't hurt to change its signature.
Previously,
Future.withEventualValue()
tried to match theFuture
constructor, with one subtle difference in behavior. It interpreted null to mean "run the function again," which causes an infinite loop if the programmer returns null without realizing. Joshua found a regression of this sort in Lime itself, one I should have caught but overlooked.This PR changes the function signature to avoid any possibility of this error. There is no return value anymore, so you can't accidentally return the wrong value. Instead, as with
ThreadPool
, you are given aWorkOutput
object and must callsendComplete()
at some point. The work function has the same signature as inThreadPool
, so if users understand the one, they'll understand the other.I have a couple other branches that are closer to how
withEventualValue()
used to work, and I can bring them back if requested. ButwithEventualValue()
is new in 8.2.0, so it shouldn't hurt to change its signature.