--- Dave Whipp <[EMAIL PROTECTED]> wrote:
> "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).
Ok. And that leads to the next thing --
> 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.
Agreed.
> 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.
Maybe. It isn't pretty, but I've seen worse. Hell, I've posted worse.
:)
> > 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) { ... };
Ok, poorly phrased on my part. I just meant I'd like to visually see
more of what's going on in the code. In other words, I'm not fond of
the syntax proposal. I find C<timeout(60) { ... }> too terse, and would
rather see a more verbose version. Merely a style issue, though. Still,
your response to what it *looked* like I meant is a good idea, too.
> > > 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.
lol -- and I was too dense to get it. :)
> 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).
Ah. Ok, but if that's the case, you could as easily write it
timeout(5) { coro { ... } };
and have the compiler build it accordingly. The same logic works either
way from that end. Thread seem more sensible for a timeout, but as a
general rule I'd probably prefer to see implicit coro's rather than
implicit threads as the default.
> 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;
> }
Dunno....returns from a single routing that are in different threads
could produce some real headaches.
> How about:
>
> sub slow {
> timeout(60) {
> throw TimeoutException.new("Error: slow_fn timed out")
> };
> return @slow_imp;
> }
I like thata lot better, but I'm still not sure how it would fly.
(Sorry for the reformat, btw -- got pretty cramped on my screen.)
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
