my and local differences

HaB has asked for the wisdom of the Perl Monks concerning the following question:

Hello.

So I am currently on a project to document someone else's code (ugh!), and from what I can tell, the programmer in question doesn't seem to be all that familiar with perl. I am seeing some things that definately run counter to things I was taught or have learned. So I figure I'd consult the Monks for clarification.

Here's the first oddment:


# at the top of the script:
  $sb="\013";
  $eb="\034";
# those two values are never altered anywhere else in the main portion
+ of the script.


# then, later...

sub whatever {
    local ($sb);
    local ($eb);
    $sb="\013";
    $eb="\034";

# rest of sub

}
[download]

Is this redundant? Wouldn't my() be better suited to do this? I'm not sure why he even wants local copies of those vars, since they never change. I guess what I'm looking for is a practical explanation of the difference between my and local, and the situations in which you would prefer one over the other. I have strict in use all the time, but I have only ever used my(), so I'm not clear on the difference.

-HaB

hword.

Comment on my and local differences Download Code

Replies are listed 'Best First'.
(Ovid) Re: my and local differences by Ovid (Cardinal) on Nov 10, 2000 at 23:11 UTC
It looks like you are right. `my` does seem to be a better fit here. However, the following might be even more appropriate, given your description: `use constant EB => "\034";` [download] That has the advantage that every knows it's a constant and not subject to change. Of course, if all you are doing is documenting, this may not be an option. I have strict in use all the time, but I have only ever used my(), so I'm not clear on the difference. `local` pushes the current copy of the variables value (if any) onto a stack and assigns a new value which is available to everything within the original scope of `local`. When that variable passes out of scope, the original value is pulled from the stack and restored. In practice, `local` is rarely needed, unless `my` cannot be used. Global punctuation variables, for example, cannot be declared lexically with `my` and therefore must use `local` if you wish to constrain their scope. `open FILE, $somefile or die $!; { local $/; # slurp mode $foo = <FILE>; } close FILE;` [download] The above snippet uses "slurp mode" to read the entire contents of a file into a scalar. `local` is in a block to ensure that the change to `$/` does not affect other portions of the program (since `$/` is global). Cheers, Ovid Join the Perlmonks Setiathome Group or just go the the link and check out our stats.	[reply] [d/l] [select]
RE: (Ovid) Re: my and local differences by HaB (Sexton) on Nov 10, 2000 at 23:29 UTC
First, thanks to everyone for the comments...all of that helps. I think the reason I've never had to use local before is that I A - rarely mess with the values to punctuation vars, and B - almost always explicitly pass a value to a subroutine that requires one, instead of relying on the global value. IOW, I use my($var) in a sub, and if I call any other routines in the sub using that var, I call them with my_sub($var); I guess it's just weird that it has never come up before. -HaB hword.	[reply]
Re: my and local differences by redcloud (Parson) on Nov 10, 2000 at 23:10 UTC
Always use `my` unless you need to use `local`. Time when you need to use `local` include: On "punctuation" variables (for example, `$_`) When you want to access the localized variable in a subroutine that you call from inside that scope.	[reply]
RE: Re: my and local differences by Fastolfe (Vicar) on Nov 10, 2000 at 23:20 UTC
Instead of mentioning the punctuation variables, I usually tell people "use local whenever you want to mask a global variable with a localized value". The "punctuation variables" are examples of global variables that you might want to change the values of in a particular scope.	[reply]
Re: my and local differences by btrott (Parson) on Nov 10, 2000 at 23:35 UTC
Take a look at mjd's article Coping with Scoping. It has a good discussion of the differences between my and local. Read Seven Useful Uses of local for when to use local.	[reply]
RE: my and local differences by lemming (Priest) on Nov 10, 2000 at 23:17 UTC
How old are these scripts? Could be from Perl 4 days when "my" didn't exist. I had scripts written pre-5 that had local, but when I was rewriting, I often would use my. For online documentation, the links at perldoc: my & local do a better job of explaining than I could.	[reply]
RE: RE: my and local differences by HaB (Sexton) on Nov 10, 2000 at 23:33 UTC
They aren't from perl4...the date in the comments is actually from August of this year. I just think it's the programmer's unfamiliarity with the language. There are other indicators that lead me to believe this. He doesn't ever use any modules, or even some of the standard lib stuff. For example, he's still packing socket addresses with: `$sockaddr = 'S n a4 x8'; $this = pack($sockaddr, $AF_INET, $port, $thisaddr);` [download] And no, the $AF_INET isn't a typo, he's setting it at the start, cause he's not even using use Socket; So... shrug -HaB hword.	[reply] [d/l]
RE: my and local differences by quidity (Pilgrim) on Nov 11, 2000 at 00:20 UTC
It could be the case that the original programmer expected that `$sb $eb` might be changed somewhere else in the script at some point. If using the given values was critical to the subroutine then it makes sense for them to be enforced whenever the subroutine is called while letting them revert to their (possibly different) values afterwards. If the sub calls other subs while it runs, then it is essential that `local` is used (in this scenario) so as to avoid broken things. If the values of these variables isn't modified anywhere else in the script though, and you have good reason to expect that they will not need to be altered at some later date, then do your best to remove the localising.	[reply] [d/l] [select]