Loading ...
Sorry, an error occurred while loading the content.

54913Re: PATCH porting.pod "First Mystery"

Expand Messages
  • Stas Bekman
    Oct 14, 2003
    • 0 Attachment
      Brian McCauley wrote:
      > Stas Bekman <stas@...> writes:
      >
      >
      >>- move the perl4 lib solution to the perl_reference.pod
      >
      >
      > Will do when I get round to that bit. I still think a mention of it
      > is needed in porting.pod to warn people away from it. If you disagree
      > simply delete the offending paragraph.

      I'm not disagreeing with you on this. But I will wait for your second patch
      and commit both at once otherwise one of the solutions gets temporary lost...

      >>- suggest turning a lexical variable declared with my() into a global
      >>variable declared with our() to avoid the closure, with the following
      >>"but"s:
      >>
      >> o if with my() it wasn't crucial to initialize the variables
      >> (since my() initialized them to 'undef'), now all variables declared with
      >> our() must be explicitly initialized.
      >
      >
      >>[Brian: notice that I prefer *not* to suggest using local() to init
      >>vars, and rather have users do that explicitly, which is a good
      >>practice]
      >
      >
      > Well I disagree with you about it being good a practice. I personally
      > consider it good practice to work in a way that minimises the number
      > of things you have to do explicitly (with the exception of
      > declarations). I can't see why you think relying on the fact that
      > local() will initialize variables to undef is any worse than relying
      > on the fact that my() will.
      >
      > But this is your document so I shall go along with your preferences.

      It's not really mine, I just happen to maintain it. From the previous
      discussion it seems that those who cared agreed that it's better to explicitly
      declare vars. Granted 'local our' works, but for (most?) users this point will
      be lost, as they will just copy-n-paste examples without understanding why is
      it so. Power users can figure it out on their own, and I wasn't against
      mentioning it at the end after explaining the longer (more explicit?)
      solution. I think that makes it a happy compromise, no?

      > I've tried to keep it brief by moving some of the points (in
      > particular 'use vars') into comments inside the code examples where
      > they can be expressed more concisely.

      Frankly, I can't understand why do you try to undermine the importance of
      always initializing variables. Please remember that this docs is used as a
      reference by users of varying expertise in Perl. Unless you are an advanced
      user and know what you are doing, it's a goodness to always initialize
      variables before you use them.

      > +The easiest and the fastest way to solve the nested subroutines
      > +problem is to switch from lexical scope to package scope for all
      > +variables for which you get the warning. The C<handler> subroutines

      Would it be better to say:

      The easiest and the fastest way to solve the nested subroutines
      problem is to switch every lexically scoped variable you get the warning for
      to a global package variable.

      or something like that? package scope is lexical scope too.

      > +are never called re-entrantly and each resides in a package to itself.
      > +Most of the usual disadvantates of package scoped variables are,
      > +therefore, not a concern. Note, however, that whereas explicit
      > +initialization is often redundant for lexical variables it is usually
      > +not redundant for these package variables as they are reused in
      > +subsequent executions of the handler.

      may I suggest the following wording:

      Note, however, that whereas explicit
      initialization is not always necessary for lexical variables it is usually
      not redundant for these global package variables as they persist in
      subsequent executions of the handler and unlike lexical variables, don't get
      automatically destroyed at the end of each handler.

      > +If the shared variable contains a reference it my hold onto lots of

      shared variable? Can we stick to lexical vs. global, and not confuse user even
      further? shared variables are special with ithreads and allow sharing data
      across threads.

      also s/my/may/

      The rest looks good. Thanks Brian.

      __________________________________________________________________
      Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
      http://stason.org/ mod_perl Guide ---> http://perl.apache.org
      mailto:stas@... http://use.perl.org http://apacheweek.com
      http://modperlbook.org http://apache.org http://ticketmaster.com
    • Show all 20 messages in this topic