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

54931Re: PATCH porting.pod "First Mystery"

Expand Messages
  • Stas Bekman
    Oct 15, 2003
    • 0 Attachment
      Brian McCauley wrote:
      > Stas Bekman <stas@...> writes:
      >>>[...] 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.
      > I assume that was a typo :-) s/declare/initialize/.

      Yes, thank you!

      >>>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.
      > I don't. On the contrary I explain the importance in the narrative
      > and also re-enforce the importance in comments in the example code. I
      > have, at your suggestion, pushed into an afterthought any mention of
      > the fact that if you need to use local() anyhow you can get away
      > without explicit initialization of package variables.
      > Since it appears you _are_ against mentioning it even at the end I'll
      > remove it completely from porting.pod. I don't care, I'm not on a
      > crusade here.
      >>Unless you are an advanced user and know what you are doing, it's a
      >>goodness to always initialize variables before you use them.
      > Of course I agree that initializing variables before you use them is
      > good. It's just that I think that implicit initialization using my()
      > or (if you can't use my(), local()) is better than explicit
      > initialization using undef(). IMNSHO, whenever one sees an explicit
      > ``$var = undef'' or ``undef($var)'' an alarm bell should ring and ones
      > first thought should be "is there a missing/misplaced my()/local()?".

      When did I say that initializing to undef is good thing? I was talking about
      initializing variables to the types there are going to use, e.g.:

      my $counter = 0; # numbers
      my $string = ''; # strings

      > BUT....
      > I can't see why we are still arguing about this. I've worded the
      > document _as_if_ I agreed with you that explicit initialization was a
      > "good thing" per se. The fact that we disagree is, therefore, surely,
      > irrelevant.

      Most likely we both try to say the same thing, but misunderstanding each other...

      >>>+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.
      > Yes, that does read more easily. But the dangling "for" now grates.
      > Particularly the juxtaposition "for to". So I'd keep the "for which"
      > even if some people consider such strict English grammar to be
      > affected.

      I guess it reads better if using commas:

      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.

      > I would drop the word "global" since global has many different
      > meanings. By one definition of "global", the orginal file-scoped
      > lexical variable was global. By another definition of "global",
      > package variables (other than ones like %INC) are not global.
      > The use of the phrase "global variable" in Perl documentation as a
      > synonym for "package variable" is AFAIK deprocated.
      > Some people use the phase "global package variable" (or "global global
      > variable" (sic)) to refer to a variable like %INC.
      > I've even seen examples where people use the phrase "global variable"
      > to mean "package variable in package main".

      Well, the problem I have with this approach is the following: I think of
      lexical variables as non-accessible from outside the scope thy exist in. This
      is incorrect for variables declared with 'our' and 'use vars', since those
      variables are accessible outside the file/package they were defined in. Which
      makes them non-lexical. No?

      >>or something like that?
      > OK:
      > The easiest and the fastest way to solve the nested subroutines
      > problem is to switch every lexically scoped variable for which you
      > get the warning to a package variable.

      sounds good.

      >>package scope is lexical scope too.
      > Er, now I'm really confused. The our() function declares a lexically
      > scoped alias for a package variable - but this is getting far too subtle.

      See my comment above.

      >>>+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
      >>>+su bsequent 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.
      > Again I dislike the word "global" for reasons already stated.
      > I think it would read better if we use consistant terminology. EITHER
      > "not necessary" v "necessary" OR "redundant" v "not redundant" but NOT
      > "not necessary" v "not redundant".


      >>>+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?
      > Er, lexical v _package_


      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