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