"Dulcimer" <[EMAIL PROTECTED]> wrote > so that the timer goes off after a
second, prints a dot, and resets
> itself to go off again after another second? And I still like the idea
> of an expanding temporal window between dots:
>
> sub slow_fn {
> my $pause = 1;
> my $timer is last { .stop } = new Timer secs => $pause++,
> reset => {$pause++},
> code => {print "."};
> return slow_fn_imp @_;
> }
I'm thinking there's a way to avoid the $pause variable:
sub slow_fn
{
my $tmp = new Timer( secs=>1, code => { print "." and
.reset(.count+1) });
return slow_fn_imp @_;
}
But exposing the object like that still bothers be: I shouldn't need the
$tmp, nor the .new. When someone writes the Std::Timer module, we can add a
macro to it such that:
sub slow_fn
{
timeout(1) { print "." and .reset(.count+1) };
return slow_fn_imp @_;
}
I think the implementation is obvious, given the previous example of the
inline code. Though s/timeout/???/.
A semantic question: what output would you expect for this:
sub silly
{
timeout(5) { print ".HERE."; sleep 4; print ".THERE." };
for 1..5 -> $count { sleep 2; print "$count" };
}
possible answers are
12.HERE.34.THERE.5
or
12.HERE..THERE.345
I'm thinking probably the latter, because its easier to launch a thread in
the codeblock than to un-launch it.
> As a sidenote, although it would actually reduce readability here, I'm
> still trying to wrap my brain thoroughly around the new dynamics of $_.
> Would this work correctly maybe?
>
> sub slow_fn {
> my $timer is last { .stop } = new Timer secs => $_=1,
> reset => {$_++},
> code => {print "."};
> return slow_fn_imp @_;
> }
>
> Isn't that $_ proprietary to slow_fn such that it *would* work?
I had to stare at it for a few moments, but yes: I think it should work (if
we define a .reset attribute that accepts a codeblock).
Dave.
