in reply to Re: Problems With Hash Pointer Assignments
in thread Problems With Hash Pointer Assignments

1. I guess that was school. 2. I would have liked it to just delete the value. But I was having problems and just tried returning the hash ref of each branch. 3. I just wanted to assign the hash structure of value into hashdata so I can use the %HashData normally in the main program. I guess I can change the name. 4. Do you mean i should use shift?
  • Comment on Re^2: Problems With Hash Pointer Assignments

Replies are listed 'Best First'.
Re^3: Problems With Hash Pointer Assignments
by gaal (Parson) on Nov 30, 2004 at 20:55 UTC
      But I was having problems and just tried returning the hash ref of each branch.
    That's not going to prove very useful, because then in the caller you'd need to assemble the branches again. delete can handle indirection: You can do something like

    delete $node->{$doomed_key}; # recurse through remaining elements

      I just wanted to assign the hash structure of value into hashdata so I can use the %HashData normally in the main program.

    That's fair enough: but you don't need to muck around with copies to achieve that. If in the caller code you have %Hash, and call your function with an argument \%Hash, any changes made indirectly to that data will show up in the caller. This is one of the main features of references.

      Do you mean i should use shift?

    It's a matter of style, so there will be differing opinions, but generally you can use my ($arg1, $arg2, ...) = @_ to get your parameters. (Sometimes shift is more appropriate, and sometimes even $_[0] etc. are the Right Thing -- but not typically.)

      Ahhhh, I almost forgot about the @_ way ! I was making copies of the Hashes before for creating a function to replace key values within the hash dimensions.