in reply to Re: Missing something with regards to references
in thread Missing something with regards to references

Thank you for the explination.

It sort of make sense to me, but this is entirely new territory for me. I'd had a hunch at one time that the undef keys beneath the one I wanted would be a problem, but I couldn't quite wrap myself around what could be done about it. Using the reference rather than copies of values sort of makes sense too, but I think it needs time to sink in. I think the part about using $_[0] instead of shift makes the least sense to me... since I am always pathing through a reference, I apparently need to make a reference to the reference?

Anyway, thank you. This is very helpful.

  • Comment on Re^2: Missing something with regards to references

Replies are listed 'Best First'.
Re^3: Missing something with regards to references
by iblech (Friar) on Nov 03, 2004 at 10:47 UTC
    since I am always pathing through a reference, I apparently need to make a reference to the reference?

    \$_[0] is not needed if the given (first) key is already a hashref. E.g.:

    my %DATA = (3 => {}); put_element($DATA{3}, ...);

    But it is needed if the key doesn't exist yet:

    my %DATA = (3 => {}); put_element($DATA{42}, ...);

    "But why doesn't my $current = \shift work? Why do I have to use my $current = \$_[0]?" Answer: If the key already exists and its value is a hashref, both possibilities work. But if the key does not exist, we have to make sure, that we really get a reference to the entry of %DATA, not the value of the non-existing entry.

    sub test1 { my $val = shift; $val = 5; } sub test2 { $_[0] = 5; } my ($a, $b) = (3, 3); test1($a); # $a continues to be 3. test2($b); # $b is 5 now.

    But I could have missed something, too.