in reply to Scope Between global and my

localizing a global variable is a reasonable way to do this. By localizing it, the variable's former value -- if it even has one -- is stored away, and restored when your subroutine returns.
If you want to be paranoid, you can select a special namespace for the variable, to make it unlikely that any other part of the program would even know about it. This will also silence any warnings you might get from use strict about global symbols requiring package names. (And you do use strict, don't you?)

Example: 


  sub main_routine {
    local @private::keep::out::data = load_huge_array();
    child_sub1();
    child_sub2();
  }

  sub child_sub1 {
    for ( @private::keep::out::data ) {
      ...
    }
  }

[download]

jdporter
The 6th Rule of Perl Club is -- There is no Rule #6.

Replies are listed 'Best First'.
Re: Re: Scope Between global and my
by SkipHuffman (Monk) on Apr 01, 2004 at 17:45 UTC

    Isn't local deprecated?

[reply]

      Absolutely not! And I've illustrated a good use for it above.

      However, I suppose it depends on whom you ask. Some people believe that since "global variables considered harmful" for other, more primitive languages, it applies to Perl as well. I disagree.

      Global variables must be used with care, of course. But then, we should be careful in all our programming, no?

      jdporter
      The 6th Rule of Perl Club is -- There is no Rule #6.

[reply]

        Ok, that worked. But strict really hates it. I am trying to be a good little Perl coder and always use strict.

[reply]
      Use of local is not deprecated, but it's not for creating new lexical variables. It "suppresses" the existing value of an existing variable for the lifetime of a given scope. 
      {
    local $x = 3;
    do_stuff();
}

      [download]
      is functionally equivalent to: 
      {
    my $secret_name_1095471 = $x;
    $x = 3;
    do_stuff();
    $x = $secret_name_1095471;
}

      [download]
      The problem with local is that it LOOKS like some handy keyword for creating locally scoped variables. But some do_stuff() might not be expecting this suppression, and they might not realize that the suppression will end without their control. No matter what do_stuff() does, the value of $x will be reverted at the end of this code's scope.

      --
      [ e d @ h a l l e y . c c ]

[reply]
[d/l]
[select]
        ... the existing value of an existing variable...

        True... for global (i.e. package) variables only. local cannot be used on lexical (i.e. "my") variables.

        By the same token, your illustrated functional equivalence is only correct if the $x is a global variable, not a lexical.
        (Also, the equivalence breaks down if $x is tied.)

        The problem with local is that it LOOKS like some handy keyword for creating locally scoped variables.
        No. That's like saying "The problem with Perl is that it looks like line noise." The problem is in people's heads, not in the language itself. When you grok what the local operator does, it is delightfully useful and unsurprising.
        But some do_stuff() might not be expecting this suppression, and they might not realize that the suppression will end without their control. No matter what do_stuff() does, the value of $x will be reverted at the end of this code's scope.
        Right. And that is a good thing. Callees aren't supposed to care what happens after they return. If you code so that they do, you are violating some of the most basic principles of structured (not to mention object-oriented) programming.

        jdporter
        The 6th Rule of Perl Club is -- There is no Rule #6.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom