David Storrs <[EMAIL PROTECTED]> writes:
> Piers,
>
> Apologies...I actually put them into one mail deliberately, because I
> didn't want to burn more mindspace than necessary...people could skim
> all my questions at once, answer those they were interested in, and be
> done. I didn't think about
At 10:34 AM -0800 3/24/03, Larry Wall wrote:
On Mon, Mar 24, 2003 at 12:05:13PM -0600, Jonathan Scott Duff wrote:
: On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
: > The purpose of a state variable is to keep state across multiple calls
: > to the same scope, so I'd say the proper sem
On Mon, Mar 24, 2003 at 12:05:13PM -0600, Jonathan Scott Duff wrote:
: On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
: > The purpose of a state variable is to keep state across multiple calls
: > to the same scope, so I'd say the proper semantics on closures is
: > to treat the genera
On Mon, Mar 24, 2003 at 01:37:01PM -0500, Dan Sugalski wrote:
Since I'd as soon not encourage this, how about INSTANTIATE? Nice and
long and therefore discouraging. :)
Nothing a macro can't fix :-D
--
Matthijs van Duin -- May the Forth be with you!
At 12:05 PM -0600 3/24/03, Jonathan Scott Duff wrote:
On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
The purpose of a state variable is to keep state across multiple calls
to the same scope, so I'd say the proper semantics on closures is
to treat the generation of a closure as a new
On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
> The purpose of a state variable is to keep state across multiple calls
> to the same scope, so I'd say the proper semantics on closures is
> to treat the generation of a closure as a new block with new state properties.
> The most useful
On Mon, Mar 24, 2003 at 06:29:10AM -0800, Austin Hastings wrote:
:
: --- arcadi shehter <[EMAIL PROTECTED]> wrote:
: > is there any chance for this to work :
: >
: > sub new_counter($start=0) {
: > return sub {
: > prop $cnt = $start; #this is opposite to "state"
: >
Piers,
Apologies...I actually put them into one mail deliberately, because I
didn't want to burn more mindspace than necessary...people could skim
all my questions at once, answer those they were interested in, and be
done. I didn't think about how this would impact the summaries.
In future, I'll
On Mon, Mar 24, 2003 at 03:23:21PM +, Piers Cawley wrote:
Are you sure about that. If state is declaring a lexically scoped
alias to a property of the block/sub, then each invocation of a will
generate a different block/sub &b, which implies that the various &b
instances won't share the same $z
David Storrs <[EMAIL PROTECTED]> writes:
> Greetings all,
>
> Ok, it took me several days to get through A6, and I'm not caught up
> on all the mail yet (though I've tried to skim so I don't repeat
> someone else's question). I'm left with a bunch of questions; can
> anyone answer the following:
Matthijs van Duin <[EMAIL PROTECTED]> writes:
> On Sat, Mar 22, 2003 at 10:24:09PM +0200, arcadi shehter wrote:
>> sub a {
>> state $x;
>> my $y;
>> my sub b { state $z ; return $x++ + $y++ + $z++ ; }
>> return &b; # is a \ before &b needed?
>> }
>>
>>
>>will all &b refer t
--- 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
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 sa
13 matches
Mail list logo
