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