> > 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.
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 @_;
}
That's only superficially different, but is a little more aesthetically
satisfying, somehow. Then again, I'm a perverse bastard, lol... :)
On the other hand, if this threads, does each call to slow_fn() get a
unique &_, or did I just completely hose the whole process? Could I say
my temp &_.timer is last { .stop } = new Timer ( ... ); # ?
or is it even necessary with temp?
> 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 @_;
> }
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.
> I think the implementation is obvious, given the previous example of
> the inline code. Though s/timeout/???/.
alarm? trigger(), maybe?
> 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.
> > 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).
lol -- I was assuming we'd have to make reset accept codeblocks, and
yes, I'd expect you to have to stare a bit. It's ugly, and I'd rather
create a new variable that do this, tho we've seen that you don't need
to.
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
