Skip Menu |
 

This queue is for tickets about the future CPAN distribution.

Report information
The Basics
Id: 124040
Status: stalled
Priority: 0/
Queue: future

People
Owner: Nobody in particular
Requestors: leonerd-cpan [...] leonerd.org.uk
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Making conditional code easier
Download (untitled) / with headers
text/plain 1.2k
The classic middle-conditional problem which in straightline code is A() if(COND) { B() } C() is awkward to express with Future-returning functions. Current best attempt looks something like A() ->then( sub { if(!COND) { return Future->done() } B(); }) ->then( sub { C() }); One possible solution would be a 'then_if' method on Future instances, which takes a condition and a code block A() ->then_if(COND => sub { B() }) ->then( sub { C() } Easy enough to implement sub then_if { my $self = shift; my ( $cond, $code ) = @_; return $self->then($code) if $cond; return $self; } Though this obviously only restricts it to conditions that don't depend on the result of A(). Another thought is a Future->if class method A() ->then( sub { Future->if(COND, sub { B() }) }) ->then( sub { C(); }) which in the case of a false condition can just yield an empty Future->done. But at that point it's not much of an improvement on ->then( sub { COND ? B() : Future->done } ) in such a small case as this, though it does win out in neatness if the B() code is in fact a much longer block of statements, rather than a simple function-call expression. -- Paul Evans
Download (untitled) / with headers
text/plain 180b
Plus a simple extension to this would be to name 'cond' instead and take an even-sized list of condition+code pairs, similar to the (cond ...) construct in Scheme. -- Paul Evans
Download (untitled) / with headers
text/plain 332b
On further thought, Future::AsyncAwait and the async/await syntax makes this entire subject a whole lot simpler, to the point that I don't really think Future itself needs to solve it. Anyone who wanted the readability in newly-written code probably wanted to be using async/await syntax, now that it largely works. -- Paul Evans


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.