"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.