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

Having read a lot of, coded a lot of and experienced a lot of other's poorly programmed code I thought I had a *very* clear understanding of the uses of globals, locals and mys in perl. Recently however I learned that either is not the case or somebody is doing something so bizarre to munge perl that I just don't want to know. I'm hoping the latter but guessing the former.

The problem is that I am creating a 'my' variable within my own personal scope within the curly braces and somebody is twiddling with my data. I had always hoped this wouldn't happen but it has. I asked the engineer's solution and he said to change the variable's name to make sure there wasn't any name collisions in the lookup table.

Hmmm... I thought constructs like my/local were supposed to prevent that? Silly me I guess. So now I am more than a little curious if there is a time when a variable declared with my really isn't getting new memory declared in the lookup table.

I would go play with the code and try using local to see if replacing the variable on the stack changed the behavior of the program but this is production code and I'd rather not be the one hosing things, especially since there is no formal test environment other than production for this.

I'm not looking for an explanation of how my works, but maybe I do because at a fundamental level the way I consider it works is wrong.

Replies are listed 'Best First'.
Re: When is my variable not really mine?
by merlyn (Sage) on Sep 07, 2000 at 17:39 UTC
    Nobody can refer to a lexical variable outside its lexical scope by name.

    However, if you hand a reference to that variable to another area, or even a reference to a closure that has visibility of the lexical variable, the variable can be tweaked at will.

    Note that a subroutine has limited "call-by-reference" semantics as well, if you directly alter @_ rather than copy the values, as is routinely suggested.

    And even if you had a copy of a top-level value, if that copy contains references, then the references are pointers into your original data structure. To fully insulate yourself, you must perform a deep copy.

    -- Randal L. Schwartz, Perl hacker

[reply]
      Well I'm not playing with references and I'm not passing this variable to anybody else, it is mine and mine alone *muhahahaha*.

      I'm starting to worry though that this code isn't being called as I'd expected and is possibly being eval'd into existance or manipulated in some way, because I've been looking more and more into it and it doesn't make sense.

      I was hoping that this problem could easily be explained by 'I know too little', but maybe I should be leaning towards 'the guy who wrote this is a code slingin' cowboy'. It isn't the first weird thing I've seen him do *chuckles*

[reply]
        I think we need more information. Merlyn is correct in that a 'my' variable cannot be referenced outside of the block, though a reference passed outside certainly can affect the value.

        What I don't understand is how you can know that the value of your variable has changed unless you're doing some execution of code within your block. If you're entering a block with a 'my' variable, leaving that block to execute some other code, and returning to it, the variable is recreated and undefined on the 2nd run. Consider: 

        sub a {
  my $var = 1;

  &b;                   # Can't touch $var

  eval $set_var_to_2;   # Code in this variable can affect $var

  print "$var\n";
}

        [download]
        If we could see some code we could explain what's going on, probably. Also make sure you're using 'strict'. This will catch lots of problems like this.
[reply]
[d/l]
(Ovid) Re: When is my variable not really mine?
by Ovid (Cardinal) on Sep 07, 2000 at 18:46 UTC
    The behavior that you describe is bizarre, so it's difficult to imagine. Try reducing the code to a minimal test case so you can isolate the error. I recently had a problem where I thought my was not localizing a variable properly and I assumed that I had a bug. As it turns out, I had a typo which several other programmers missed, but reducing to a minimal test case (I was going to post it here if I could replicate it) revealed my problem.

    If you're curious, here's what happened with me: At the top of my program, I had 

    my @data;

    [download]
    In one of my subs, I forgot parens around a set of variables I was declaring: 
    my @stuff, @data;

    [download]
    Guess what? I didn't localize @data (had I been more creative with my variable names, strict would have caught this). It took me quite a while to spot that. I thought I had a genuine bug in DBI uncovered.

    Remember, get a minimal test case and if you still have it, post the code and we'll get to work :)

    Cheers,
    Ovid

    On a side note: I always think I've found a problem in Perl, or DBI, or CGI, only to discover that the problem is my code. In a year of doing Perl, I've only encountered one actual bug in Perl. I'll be good money that the issue is your code.

[reply]
[d/l]
[select]
RE: When is my variable not really mine?
by spudzeppelin (Pilgrim) on Sep 07, 2000 at 18:57 UTC

    You wouldn't happen to be using mod_perl, would you? If you're using mod_perl, and not BOTH useing strict; and explicitly declaring a package, you can run into wild namespace collisions within a particular Apache child process.

    Spud Zeppelin * spud@spudzeppelin.com

[reply]
[d/l]
[select]
      I don't think this is a namespace issue. He's talking about problems with the scoping of his variables. It sounds like everything is local to the same namespace (package).
[reply]

Back to Seekers of Perl Wisdom