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
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-8594-1515509896-1858.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1249
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
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-8594-1515509896-1858.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-8594-1515509896-1858.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-8577-1515510469-453.124040-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 180
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
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-8577-1515510469-453.124040-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-8594-1515509896-1858.0-0-0 [...] rt.cpan.org> <rt-4.0.18-8577-1515510469-453.124040-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-23563-1556279189-904.124040-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 332
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.