Re: PATCH porting.pod "First Mystery"

2003-09-05 Thread Stas Bekman
Brian McCauley wrote: [...] OK, your last post's examples were more to the point of wanting to destroy objects at the end of the request, and hence here is a new summary: - move the perl4 lib solution to the perl_reference.pod - suggest turning a lexical variable declared with my() into a global

Re: PATCH porting.pod "First Mystery"

2003-09-05 Thread Brian McCauley
Stas Bekman <[EMAIL PROTECTED]> writes: > local is perl4-ism, nowadays it's used only for localizing special > perl variables, like $|. Using package variables and local() in to do the job of block-scoped lexicals is a Perl4-ism. On the other hand, when using global variables (in which I include

Re: PATCH porting.pod "First Mystery"

2003-09-03 Thread Stas Bekman
Perrin Harkins wrote: To summarize: - move the perl4 lib solution to the perl_reference.pod - suggest replacing my() with our() to avoid the closure, however this change requires that the variables will be initialized before used in most cases (example of 'open our $foo' which doesn't need to b

Re: PATCH porting.pod "First Mystery"

2003-09-03 Thread Perrin Harkins
On Wed, 2003-09-03 at 21:24, Stas Bekman wrote: > [...] > >>In effect you use local() to undef the variable, instead of explicitly > >>initializing it. Why not doing this explictly? > > > > > > Firstly it's conceptually neater to use local. I want to think of the > > variable as local rather tha

Re: PATCH porting.pod "First Mystery"

2003-09-03 Thread Stas Bekman
[...] In effect you use local() to undef the variable, instead of explicitly initializing it. Why not doing this explictly? Firstly it's conceptually neater to use local. I want to think of the variable as local rather than as a global variable that needs to be explicitly reset. local is perl4-i

Re: PATCH porting.pod "First Mystery"

2003-09-03 Thread Brian McCauley
Stas Bekman <[EMAIL PROTECTED]> writes: > Brian McCauley wrote: > [...] > >>Nice, but: > >> > >> > +The easiest and the fastest way to solve the nested subroutines > >> > +problem is to change C to C C for all variables for > >> > +which you get the warning. The C subroutines are never > >>... >

Re: PATCH porting.pod "First Mystery"

2003-09-02 Thread Stas Bekman
Brian McCauley wrote: [...] Nice, but: > +The easiest and the fastest way to solve the nested subroutines > +problem is to change C to C C for all variables for > +which you get the warning. The C subroutines are never ... [...] > + local our $counter = 0; local our? That should be either local

Re: PATCH porting.pod "First Mystery"

2003-09-01 Thread Brian McCauley
Stas Bekman <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > In private mail Stas Bekman <[EMAIL PROTECTED]> writes: > > > >>oops, that should be the modperl list... at modperl-docs we discuss > >>mostly site/docs techical issues and there are very few people on this > >>list to get enou

Re: PATCH porting.pod "First Mystery"

2003-08-30 Thread Stas Bekman
[EMAIL PROTECTED] wrote: In private mail Stas Bekman <[EMAIL PROTECTED]> writes: oops, that should be the modperl list... at modperl-docs we discuss mostly site/docs techical issues and there are very few people on this list to get enough exposure for this kind of feedback request. Patch for "T

PATCH porting.pod "First Mystery"

2003-08-22 Thread nobull
In private mail Stas Bekman <[EMAIL PROTECTED]> writes: > oops, that should be the modperl list... at modperl-docs we discuss > mostly site/docs techical issues and there are very few people on this > list to get enough exposure for this kind of feedback request. Patch for "The First Mystery" sec