"Dulcimer" <[EMAIL PROTECTED]> wrote > > But exposing the object like that still bothers be: I shouldn't need > > the $tmp, nor the .new. > > I'm not so sure I agree with losing the new(). I kinda like that just > for readability. Less isn't always more. :) > > Ok, how about this: > > sub slow_fn { > temp &_.timer is last { .stop } = new Timer ( > secs => 1, code => { .reset += print "." } > ); > return slow_fn_imp @_; > }
Wrong semantics: First, you're assuming that .reset is an attribute, rather than a command (Yes, I believe the command/query separation, where possible). Second, My intention was that if C<print> ever fails (e.g. broken pipe), then I'd stop resetting the timer. Your program meerly stops incrementing the timeout. Even if we assume that the "temp &_.prop" thing works, I'm not sure I'd want it littering my code. I could see it being used in a macro defn though. > Dunno -- I see what you're doing, but it's a little *too* helpful. > I'd rather see a few more of the engine parts on this one. We can expose a few more parts by having the macro return the timer object, so you could write: my $timer = timeout(60) { ... }; > > 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. > > un-launch? If they're threaded, aren't they running asynchronously? > I see 12.HERE.34.THERE.5 as the interleaved output. I have no idea what > you mean by "un-launch", sorry. Sorry, it was my feeble attempt at humor. What I was getting at is that, if we assume the codeblock executes asa coroutine, then you'd get the latter output. If you wanted a thread, you could write: timeout(5) { thread { ... } }; but if we assume that the codeblock is launched as an asynchronous thread, then there is no possible way the coerce it back into the coroutine (i.e. to "un-launch" it). Now here's another semantics question: would we want the following to be valid? sub slow { timeout(60) { return undef but "Error: timed out" }; return @slow_imp; } How about: sub slow { timeout(60) { throw TimeoutException.new("Error: slow_fn timed out") }; return @slow_imp; } Dave.