Future improvements to FutureVar

[cpurdy]

We've been using the @future annotation and the corresponding type and API (FutureVar) quite a bit lately, and it's been good to really give it a work-out. The @Future annotation is FutureVar; there's a file that allows names to be automatically imported, and "FutureVar" is imported as "Future", so @Future is how it gets mixed in to a variable:

@Future Int n = someService.foo();

Generally, we put a stick in the ground with design, and then wait until we give it a real work-out before trying to improve the design. Now that's we've been using FutureVar "in anger", we have a pretty good idea of some improvements that are needed. There's some simple stuff, like getting rid of the createContinuation() method. But there are bigger things; for example, FutureVar is simply too (pardon the pun) generic. With conditional mix-ins, we can create FutureVar APIs that are tailored to various types, such as Boolean. You can see conditional mix-ins used extensively with Array, for example.

You could imagine constructs such as:

Boolean result = foo^().otherwise(bar());

Perhaps, async short circuit logic like:

// executes the "then" portion as soon as the first one of `foo` and `bar` returns a True: 
if (foo^().or(bar^())) {...}

// executes the "else" portion as soon as the first one of `foo` and `bar` returns a False: 
if (foo^().and(bar^())) {...}

Some other possibilities:

<NewType> FutureVar!<NewType> ifThen(function NewType() processThen,
                                     function NewType()? processElse = Null)
<NewType> FutureVar!<NewType> otherwise(function NewType() processElse = Null)
FutureVar!<Boolean> negate(); // ... or "not()"?
FutureVar!<Boolean> and(Future<Boolean>);
FutureVar!<Boolean> and(function Boolean());
FutureVar!<Boolean> and(Boolean);
FutureVar!<Boolean> or(Future<Boolean>);
FutureVar!<Boolean> or(function Boolean());
FutureVar!<Boolean> or(Boolean);

Exceptions are still a bit tedious to handle, but it's not apparent that there are better approaches than the current handle() method. A void exception handler might be nice:

foo^().swallow(e -> log(e));

Depending on what other methods are introduced that could be chained, it might also be nice to have a simple, non-altering "wait for completion" method, like:

foo^().wait().someOtherChainedFutureMethod();

But there is also a use case for a "service has timed out, so now use the backup plan" method; perhaps something like:

FutureVar!<Referent> onTimeOut(Duration timeout, function Referent() backupPlan)

I just wanted to capture some of these ideas that we've been discussing here, for future reference. None of this is critical path for the current project, but there are some definite "nice to haves" that we should be considering, for when we get around to opening up this patient.

[markandrewfalco]

One thing which I’ve done recently with Java’s CompletableFuture is have interfaces which separate the producer and consumer side of the CF interface, it is quite odd that in Java consumers are allowed to complete their future other then via cancelation.