Is it possible to create 'cold' (lazy evaluated) tasks?

[delebedev]

E.g. I have wrapped some non-task code as following:

- (BFTask<NSNumber *> *)actionSheetTask {
    UIAlertController* alert = [UIAlertController alertControllerWithTitle:nil
                                                                   message:nil
                                                            preferredStyle:UIAlertControllerStyleAlert];
    BFTaskCompletionSource *source = [BFTaskCompletionSource taskCompletionSource];

    [alert addAction:[UIAlertAction actionWithTitle:@"Camera" style:UIAlertActionStyleDefault handler:^(_) {
        [source setResult:@0];
    }]];

    [alert addAction:[UIAlertAction actionWithTitle:@"Cancel" style:UIAlertActionStyleCancel handler:^(_) {
        [source cancel];
    }]];

    [self presentViewController:alert animated:YES completion:nil];
    return source.task;
}

Now I'm calling:

[self actionSheetTask];

Obviously it presents alert, but is it possible to actually 'defer' presenting of alert untill somebody does this:

[self actionSheetTask] continueWithBlock

[richardjrossiii]

An interesting proposal. There certainly is no such beast built into bolts, but it should be rather trivial to roll your own using a few solutions....

#1: Subclass, and make all of the continueWith: methods invoke the block to execute.
#2: Create a proxy object, that intercepts all messages and take the ones that begin with continueWith:, and use that as an indicator to start the 'real' task.

Though neither of those are perfect.

Overall I don't personally think that lazy tasks make sense for most uses of promises, especially as they're mostly consumed/produced in a cross-library fashion, where it wouldn't be 100% clear that the task is intended to be lazily evaluated.

I'll let others weigh in on their thoughts here, though.

cc @nlutsenko @grantland @stanleyw @wangmengyan95 @hallucinogen

[nlutsenko]

Agreed with the fact that lazy tasks don't quite fit promises, due to the fact that task is something produced in response to the action being taken, and resolved when the action is done.

Lazy evaluation is an interesting idea overall, I can't quite see how it fits into existing model of Bolts.Tasks, though.

[delebedev]

Actually I agree with @nlutsenko. Probably it was my ReactiveCocoa experience suggesting me that [self actionsheetTask] should not do anything. Now I kinda see model of bolts more clearer.

AFAIK, rac2 had the issue with distinguishing between lazy/non lazy signals.

Feel free to close this ticket. Thanks for the feedback!