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


Reply via email to