in reply to Re: Short invocation for per-object methods
in thread Short invocation for per-object methods

You did all this to avoid typing a couple of arrows? I think your lazy-meter is going in the wrong direction here.

Well, it's not the arrows that bother me, just the number of keystrokes. Especially during testing I tend to have a debug call almost every other line, so they do add up.

But you're probably right that convenience now is not worth the extra maintenance headaches my convoluted solution would cause.

In short, putting an object into a global variable is only a good idea if you want a singleton.

The way I did it I don't think the global scope of that global variable will ever contain an object, so I wasn't too worried about that part

Also, use of local() is kind of a last resort these days. I use it in a couple of situations where it's dramatically easier than the alternative, but there aren't many of those. It's likely to trip you up at some point.

Using my obviously wouldn't work since debug wouldn't be able to get to it, and I think just omitting the local would cause re-entrancy issues. So local seemed like the only solution.

You could easilly simplify to $self->debug($text) with no risk, just by making a debug() method that calls $self->{'debug'}. If you really want the debug code ref to differ by object, that's as good as you're likely to get without doing risky things.

I thought of doing that but didn't think it went far enough.

Based on your reply, I think I'll settle on using $self->debug() because of the extra flexibility over the $self->{'debug'}->() call, and just adding a shortcut to my editor to paste it into the code.

Thanks for knocking some sense into me :)

Replies are listed 'Best First'.
Re^3: Short invocation for per-object methods
by perrin (Chancellor) on Jan 04, 2007 at 15:45 UTC

    The way I did it I don't think the global scope of that global variable will ever contain an object, so I wasn't too worried about that part

    You know, I think you're right about that, which makes me think this never would have worked anyway. The $self referred to by your debug method is the our $self, which never has anything in except in a local scope.

    Using my obviously wouldn't work since debug wouldn't be able to get to it, and I think just omitting the local would cause re-entrancy issues. So local seemed like the only solution.

    That's kind of what I was getting at: when local is the answer, it usually means you're asking the wrong question. It is very useful in a couple of specific cases though, so I can't say it shouldn't ever be used.

[reply]

      my provides static binding.
      local our provides dynamic binding.

      Both have their uses. The latter would allow me to set $Carp::Verbose for just one call to carp, for example. 

      {
   local $Carp::Verbose = 1;
   carp(...);
}

      [download]

      (Mind you, not a good example, since I could just have called croak.)

      And just to show that it works: 

      sub bar {
   print our $var, "\n";  # Prints 2
}

sub foo {
   local our $var = 2;
   bar();
}

our $var = 1;
foo();

      [download]
[reply]
[d/l]
[select]
        I use it for file slurping (local $/) and for DBI (local $dbh->{'AutoCommit'}). The latter looks strange, but works because of the way DBI is implemented, and makes AutoCommit automatically snap back to its old value when I leave the current scope.
[reply]

In Section Seekers of Perl Wisdom