--- arcadi shehter <[EMAIL PROTECTED]> wrote:
> Matthijs van Duin writes:
> >
> > A nice example is:
> >
> > sub a {
> > state $x;
> > my $y;
> > my sub b { return $x++ + $y++; }
> > return &b; # is a \ before &b needed?
> > }
> >
> > Every call to sub a will return a different closure. The $x in
> each closure > all refer to the same variable. Each closure's $y
> however is different and
> > independent.
> >
>
> does it make any sence to attach "but" properties to closure ?
> if $x is a trait ("is" property ) of block associated with "sub a" ,
> is it correct to think of $x,$y as "but" properties of the block
> associated with "sub b" ?
>
> is there any chance for this to work :
>
>
> sub new_counter($start=0) {
> return sub {
> prop $cnt = $start; #this is opposite to "state"
> #which sets trait of the block ,
> #so presumably , this is created
> #anew every time closure is created
> return ++$cnt;
> }
> }
>
Interesting notion. However, given that $cnt is "static", this seems
like one of those places where a good optimizer might always return the
same sub -- treating the entire thing as a constant expression.
So this is really a kind of semantic question: does the sub on the rhs
always imply run time consideration, or might a sub-expr be considered
a constant and be folded?
(This has interesting implictations for simple generators, since the
above syntax is short and sweet, while the usual "make it an object"
implementation looks stupid and ungainly.)
=Austin
> our &counter = new_counter ;
> our &another_counter = new_counter ;
>
> print counter, counter,
> another_counter, another_counter ;
> #prints: 1 2 1 2
>
>
> arcadi .
