in reply to Re: A hash slice but not..
in thread A hash slice but not..

What case does yours handle that his doesn't? Honestly, I think the elegant eval wins the prize here. Perl's autovivify doesn't have the problems you state yours has. I do rather like your array-ref style argument passing tho.

Update: Nevermind, repeat after me kids, "eval is a four letter word". =)

--
$you = new YOU;
honk() if $you->love(perl)

Replies are listed 'Best First'.
Re (tilly) 3: A hash slice but not..
by tilly (Archbishop) on Feb 15, 2001 at 00:53 UTC
    The eval does not handle the keys being arbitrary data.

    I prefer the loop.

      Ack, =) The same thing I scolded him for on the $value thing. I'd likely rewrite the join with a foreach that makes $tree[0] entries and still let perl handle the autoviv.

      Update: Nevermind, repeat after me kids, "eval is a four letter word". =)

      --
      $you = new YOU;
      honk() if $you->love(perl)

Re: Re: Re: A hash slice but not..
by chipmunk (Parson) on Feb 15, 2001 at 00:59 UTC
    Why does mine have to handle cases that his doesn't? It's just another way to do it. Anyway I didn't see his solution until after I posted mine, because I was testing my code and revising my text.

    Still, here's a case that mine handles differently from his:

    add2hash(\%tree, 1, ('print "Hello world!\n"')); set_nested_value(\%tree, ['print "Hello world!\n"'], 1);
    ;)

    BTW, relying on Perl's autovivify (as in the eval solution) does have the same problems mine has. In the snippet: $href->{a}{b}{c} = 7; If the value of $href->{a} is a string, then Perl will treat it as a symbolic reference and an error will occur under strict refs.

    Similarly, if the value of $href->{a}{b}{c} is a reference to another hash, then the above snippet will replace that hash reference with the value 7.

    Update: On second thought, just in case someone wants to run the test case, I replaced `rm -rf *` with print "Hello world!\n". :)