Don't do this. It makes for long, painful debugging sessions.
Instead of: 
local($object1->{field}) = $val;
local($object2->{field}) = $val;
local($object3->{field}) = $val;

[download]
That's too much typing! Instead, 
for ($object1,$object2,$object3) {
  local($_->{field}) = $val;
}

[download]
So much nicer to look at, but completely, utterly wrong.

Replies are listed 'Best First'.
Re: Anti-snippet (or, "local" considered dangerous to fools")
by jeffa (Bishop) on Aug 06, 2003 at 17:23 UTC
    Indeed. Reserve the use of local for Perl built-in vars, for example: 
    my $file_contents_as_scalar = do{local $/;<FILEHANDLE>};

    [download]
    This "temporarily" undefines $/ so that the entire file handle is read into a scalar without resorting to appending inside a while loop.

    Using local on lexical or package variables can be dangerous. For your example, surely the better way to assign that variable to multiple classes is: 

    $_->{field} = $var for @object;

    [download]
    You did store your objects in a container didn't you? ;)

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]
[select]

      Using local on lexical or package variables can be dangerous.

      You can reduce that to:
      "Using local can be dangerous."

      See also Coping with Scoping. In short: don't use local on variables not mentioned in perlvar. Do use local on variables mentioned in perlvar.

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

[reply]
      Well, I would agree that local is to be avoided where possible, but it's rather hard in this case: 
      sub main_loop {
  local($dbh->{AutoCommit}) = 0;
  ... lots of code here, with multiple returns
}

      [download]
      To avoid a problem with DBD::Pg, I have all my database connection handles set to "AutoCommit" (otherwise, they start a new transaction after every COMMIT; daemons thus hold open transactions for hours at a time, waiting for the next request). I turn the AutoCommit setting off just before starting to process something. I could turn it back on, but I'd have to put that before each and every return statement. Making a lexical copy of the object doesn't help: 
        my $tmp_dbh = $dbh;
  $tmp_dbh->{AutoCommit} = 0;  #BZZT!

      [download]
      because they're handles, what you do to one affects all the copies. What I really need is a continue block for subroutines ... 
      # Wishful thinking
sub main_loop {
  ... stuff happens ...
} continue { ... oops! I must have returned! }

      [download]
      Perhaps I could do this with a naked block? 
      sub main_loop {
 {
   ... stuff happens ...
   ... use 'last' instead of 'return'?
 }
 ... restore settings here
}

      [download]
      but local for all its shortcomings, is much easier to understand by the next guy (or is it?). As to the idea of a container: no, but not applicable in this case. One object is the return value of a subroutine (and is a package variable from elsewhere), the other is a package variable in the current package.
      --
      Jeff Boes
      Database Engineer
      Nexcerpt, Inc.
      vox 269.226.9550 ext 24
      fax 269.349.9076
       http://www.nexcerpt.com
      ...Nexcerpt...Connecting People With Expertise
[reply]
[d/l]
[select]

Back to Cool Uses for Perl