http://www.perlmonks.org?node_id=1041115


in reply to Merging arrays

TIMTOWTDI¹...

...your AoH w/o extra modules and complicated maps using a temporary hash-slice:

DB<100> @array = qw( 111 222 333 444 555 888 ); => (111, 222, 333, 444, 555, 888) DB<101> @array2 = qw( acct1 acct2 acct3 acct4 acct5 acct8 ); => ("acct1", "acct2", "acct3", "acct4", "acct5", "acct8") DB<102> @temp{@array}=@array2 => ("acct1", "acct2", "acct3", "acct4", "acct5", "acct8") DB<103> @AoH = map { { $_ => $temp{$_} } } @array => ( { 111 => "acct1" }, { 222 => "acct2" }, { 333 => "acct3" }, { 444 => "acct4" }, { 555 => "acct5" }, { 888 => "acct8" }, )

(ignoring your typo)

¹) Note elements of @array must be unique ...

Cheers Rolf

( addicted to the Perl Programming Language)

Replies are listed 'Best First'.
Re^2: Merging arrays
by AnomalousMonk (Archbishop) on Jun 28, 2013 at 02:19 UTC
    ... elements of @array must be unique...

    That strikes me as a drawback. After all, there seems to be nothing inherent in the organization of the two source arrays to suggest such a limitation. Why shouldn't one be allowed to end up with data like:

    my @AoH = ( { 111 => "acct1" }, { 111 => "hoo" }, { 111 => "ha" }, { 111 => "foo" }, { ... => "..." }, { 888 => "acct8" }, );
      > Why shouldn't one be allowed to end up with data like:

      No special reason.

      Sometimes one has data structure which have to be unique, then using a hash is handy.

      Sometimes not ... I'm just listing another way to do it for one of those loosely defined PM requirements... :)

      FWIW I'll change my post to make the restriction clearer ...

      update

      The question is rather how to design functional constructs like map which can easily (idiomatically) be used/combined to create nested data-structures which solve all possible requirements (sorted, nested, unique, non-string keys, ...).

      Thats more a design than an implementation question, I rarely see people using List::MoreUtils here.

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        ... loosely defined ... requirements...

        Yes, that's always the tricky bit: to divine what the OPer really wants... or, better yet, needs!