[RFC] shortcut for chained `then`s

[yanick]

So in my code I have a bunch of chained thens:

    $rpc->api->vim_get_current_buffer
        ->then(sub{ $buffer_id = ord $_[0]->data })
        ->then(sub{ $rpc->api->vim_input( "1GdG" ) })
        ->then(sub{ $rpc->api->buffer_insert( $buffer_id, 0, [ 
            map { $_->{description} } $tw->export_tasks
        ] ); });

which I already can de-noisify a wee bit via:

    reduce { $a->then($b) } 
        $rpc->api->vim_get_current_buffer,
        sub{ $buffer_id = ord $_[0]->data },
        sub{ $rpc->api->vim_input( "1GdG" ) },
        sub{ $rpc->api->buffer_insert( $buffer_id, 0, [ 
            map { $_->{description} } $tw->export_tasks
        ] ); };

I'm wondering, though, if it would be worthwhile to have a special case of then where

$p->then( \@then, $else )

gets expanded to

$p->then( $then[0] )->then( $then[1] )->..->catch($else)

to that the above code would become

    $rpc->api->vim_get_current_buffer->then([
        sub{ $buffer_id = ord $_[0]->data },
        sub{ $rpc->api->vim_input( "1GdG" ) },
        sub{ $rpc->api->buffer_insert( $buffer_id, 0, [ 
            map { $_->{description} } $tw->export_tasks
        ] ); }
    ]);

Alternatively, if the different behaviors of then feels wrong, perhaps a chain method that does

    $p->chain( @then );
    # equivalent to
    reduce { $a->then($b) } $p, @then;

?

If any of those feel appealing to you, I'd be delighted to submit a patch.

[stevan]

I like the chain idea, please proceed with the path.

[yanick]

Dealt with with #47. Closing this ticket.