On Mon, Mar 08, 2004 at 11:57:04PM +0000, Dave Mitchell wrote: : On Sat, Mar 06, 2004 at 06:39:44PM -0800, Larry Wall wrote: : > my @x will begin {...} # at BEGIN time : > my @x will check {...} # at CHECK time (redefined to unit check) : > my @x will init {...} # at INIT time : > my @x will end {...} # at END time : : Sorry, perhaps I wasn't paying close enough attention, but suddenly we've : leaped from oddly named subs that get called at interesting times, to : array variables with oddly-named properties (or attributes, or whatever). : Je ne comprend pas :-(.
Oddly named subs are cool as such, but there are times when you don't so much want an oddly named sub as an oddly named method. These are just oddly named methods on the container in question (which certainly doesn't have to be an array). Underneath they're still oddly named subs in terms of when they run. But they implicitly get (as their first argument/invocant/topic) the container in question, so they can do fancy things with $_ and .foo and C<when> and such. The "will first" syntax is mentioned in A6. Plus we discussed it last April with respect to "state" variables--see message below. Larry >From [EMAIL PROTECTED] Tue Apr 15 11:56:23 2003 Date: Tue, 15 Apr 2003 11:19:42 -0700 From: Larry Wall <[EMAIL PROTECTED]> Subject: Re: Initializations outside of control flow To: [EMAIL PROTECTED] On Tue, Apr 15, 2003 at 10:34:35AM -0400, Mark J. Reed wrote: : It just seems like there should be a way to accomplish that without : the visual clutter. Perhaps a trait: : : my $count is initially($INITIAL_VALUE); : : If there's already a defined way of doing that in Perl 6, please : point me at it and I'll go away chastened but happy. Otherwise, : does this seem a reasonable approach? Ideas for a better name for : the trait? The traits in question are already named corresponding to the various initialization closures, which at the moment are named BEGIN {...} CHECK {...} INIT {...} FIRST {...} ENTER {...} so, since the variable in question is the topic of the closure, we have my $count will begin { .set($INITIAL_VALUE) } my $count will check { .set($INITIAL_VALUE) } my $count will init { .set($INITIAL_VALUE) } my $count will first { .set($INITIAL_VALUE) } my $count will enter { .set($INITIAL_VALUE) } Perhaps those particular traits are smart enough to distinguish whether they have a closure or not, and build an appropriate closure if not, so we could also have my $count is begin($INITIAL_VALUE) my $count is check($INITIAL_VALUE) my $count is init($INITIAL_VALUE) my $count is first($INITIAL_VALUE) my $count is enter($INITIAL_VALUE) At the moment, I believe that = always happens at run-time. So my $count = BEGIN { calculation() } would do the calculation at compile time but assign the resulting value every time the statement is executed. This means that a declaration like: state $where = $x; is almost certainly incorrect. It should probably be one of state $where is begin($x); state $where is check($x); state $where is init($x); state $where is first($x); Could go so far as to lose the "is", treating these as variants of "is". state $where begin($x); state $where check($x); state $where init($x); state $where first($x); The other possible approach would be to allow blockless closures like BEGIN (state $where = $x); CHECK (state $where = $x); INIT (state $where = $x); FIRST (state $where = $x); Maybe the parens aren't necessary, if they just introduce a syntactic statement: BEGIN state $where = $x; CHECK state $where = $x; INIT state $where = $x; FIRST state $where = $x; But I think it would be a mistake to have = running at random times depending on either the "foo" and "BAR" in foo $x = BAR { ... } Larry