Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

my $cache = undef if undef;

by szabgab (Priest)
on Jan 26, 2005 at 16:43 UTC ( #425267=perlquestion: print w/replies, xml ) Need Help??

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

I am still in maintenance mode. Here is a piece of code.
@matrices = qw(user_group user_realm group_realm realm_template template_subsite realm_subsite);
and later in the code
sub IsMatrix { shift if UNIVERSAL::isa($_[0], __PACKAGE__); my ($child, $parent) = @_; my $cache = undef if undef; + + unless ($cache) { my %cache; @cache{@matrices} = (1) x scalar(@matrices); $cache = \%cache; } + return $cache->{"${child}_$parent"}; }
OK, so the first line lets me use this either as function or as a method.

What does this my $cache = undef if undef; do ?

Just thinking aloud as the comments are coming in. Maybe I can replace the whole sub with the following:

grep /^${child}_$parent$/, @matrices;

Replies are listed 'Best First'.
Re: my $cache = undef if undef;
by Aristotle (Chancellor) on Jan 26, 2005 at 17:14 UTC

    Sorry to all the previous commenters, but they're all wrong. Tanktalus is close with his second bullet point, but then he says it doesn't work, which is wrong.

    That piece of code makes a pseudostatic variable, ie one that persists across calls to the function.

    This is known as the my $foo if 0 trick. The if undef in your code is the same thing painted green: a false condition.

    This shouldn't be used in production code. Tanktalus' suggestion of using a closed-off scope is what you should replace it with.

    Makeshifts last the longest.

      Thanks, for that nice and surprising explanation. Looks like the dark side of perl.

      Thanks for the update/correction ... although saying that I'm wrong is merely semantics. The URL you point to leaves me with the impression that Larry is implying that this could change in the future - whether that is within Perl5 (as the implication at the time could have been) or Perl6, is left open. Given that, I would suggest that any statement implying that this code "works" is misleading. It happens to work with a current version of perl, but is open to breakage under newer versions of perl (including PONIE), with Larry not sounding too concerned about it.

      I'm somewhat curious if intervening memory usage could clobber this trick - e.g., calling IsMatrix early, then using 200MB of memory, then coming back and calling IsMatrix a second time. Or does this trick make Perl think it's static (closed-off scope with lexical references in a global sub), thus leaking memory where, without the if 0, it would not be a memory leak? (I realise that "memory leak" is debatable here.)

        No, that's not how Perl manages memory. I've dug into this code lately, so here's a slightly fuller explanation that only has a few oversimplifications (as far as I know).

        When Perl compiles a subroutine, it attaches a couple of arrays to the subroutine. These are lexical pads. The first array holds several other arrays. The first contained array holds the names of all lexical variables. The second contained array holds the values of all lexical variables. (I believe subsequent contained arrays hold values on recursion, but I haven't dug that deeply.)

        The compile-time effect of my is to create an entry in the pad, storing the appropriate name in the first contained array and making a space in the second contained array for the value of that lexical variable.

        The run-time effect of an assignment to a lexical variable is to store the appropriate value in the second contained array. If there's a conditional, though, that assignment won't happen.

        For reasons of optimization, I believe that Perl doesn't reset all elements in the contained arrays to undef when it leaves a subroutine. Thus if your assignment doesn't happen due to a false conditional, you could see an old value persist through invocations.

        As far as I know, the memory won't change location; if you use up megabytes of heap memory elsewhere, there should be no effect on the lexical pads unless you exhaust all real and virtual memory and then you have bigger problems.

        It cannot be clobbered, and there are no memory leaks in either case. It's an effect of how the pads for lexical variables are maintained by the Perl core. Larry didn't want to promise this will always work, but it's very unlikely to break, since it's kind of an accidental feature of the Perl guts architecture. A lot would have to change to break it.

        Makeshifts last the longest.

Re: my $cache = undef if undef;
by Tanktalus (Canon) on Jan 26, 2005 at 17:04 UTC

    It's someone being less clever than they think they are. They think that:

    • $cache being assigned undef is an expensive operation, so by using "if undef", which is always false, we'll save on the actual assignment, and since perl already guarantees an uninitialised variable to be undef, it'll still be undef. This is supposedly more readable since you can still see $cache is set to undef. I would disagree - the "if undef" part is just plain confusing and should be removed. Whether you want to leave the assignment, "= undef", or not, is a matter of personal taste. In cases like this, I probably would leave it in, again, to make it explicit, but others like to play golf a bit more than I do, and would tell you to remove it, too - doesn't really matter.
    • The original author also thought that this would have $cache be static or something, and so we'd generate the cache only once, no matter how many times it's called. They're definitely wrong here, too. A couple of options - move the "my $cache" line to outside the sub, or do that and also put braces around the whole thing. As an example of the latter:
      { my $cache = undef; sub IsMatrix { shift if UNIVERSAL::isa($_[0], __PACKAGE__); my ($child, $parent) = @_; unless ($cache) { my %cache; @cache{@matrices} = (1) x scalar(@matrices); $cache = \%cache; } + return $cache->{"${child}_$parent"}; } }
      The outter braces are the optional part. With them, $cache is only visible inside IsMatrix, without them, the variable is visible to the entire file. With the braces is closer to the original author's intent, but I'm not sure the original author's intent is really that important given these mistakes ;-)
    Hope that helps.

Re: my $cache = undef if undef;
by Random_Walk (Prior) on Jan 26, 2005 at 16:56 UTC

    Nothing !

    I stand very much corrected, this is a cunning (mis?)feature, see Aristotle's reply below and chromatic's++ explaination

    $ perl -le'print "something" if undef' $ $ # A tumbleweed blows across my vacant screen $ perl -le 'if (undef) {print "something"} else {print "nothing"}' nothing $

    Perhaps it was a bizarre way of "commenting out" the undefing of $cache.

    Back when I worked PC support my boss ordered some parallel printer cable 'gender benders. He got 20 Male-Male, 20 Female-Female and 20 Female-Male just 'cos they were in the catalogue. I stored them under 7mm extension cable. This line somehow reminds me of that.

    I think Tanktalus has hit the nail on the head below, it is perhaps an attempt to be more obvious than just my $cache but a fairly odd one


    Pereant, qui ante nos nostra dixerunt!
Re: my $cache = undef if undef;
by borisz (Canon) on Jan 26, 2005 at 16:55 UTC
    What does this my $cache = undef if undef; do ?
    Nothing! Remove the line.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://425267]
Approved by Mutant
Front-paged by grinder
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2021-04-19 06:04 GMT
Find Nodes?
    Voting Booth?

    No recent polls found