my ($color, $fruit) = (
   $hoa->{keytwo}->[$idx_color],
   $hoa->{keytwo}->[$idx_fruit]
);
[download]

is equivalent to

my $aref = $hoa->{keytwo};
my ($color, $fruit) = (
   ${$aref}[$idx_color],
   ${$aref}[$idx_fruit]
);
[download]

Since you're dealing with one array (@{$aref}), yes, you can use a slice:

my $aref = $hoa->{keytwo};
my ($color, $fruit) = @{$aref}[$idx_color, $idx_fruit];
[download]

or back in one line:

my ($color, $fruit) = @{$hoa->{keytwo}}[$idx_color, $idx_fruit];
[download]

Notice I used <sigil>{$aref}. I did so because it parallels <sigil>array exactly. $aref->[] is a shortcut for ${$aref}[] exclusively, so it's useless when dealing with array slices.

Update: oh, I forgot to answer the second question! There's nothing wrong with HoA in general. In your situation, a hash would work nicely since you're naming your parameters anyway.

If you go with hashes, you can take hash slices:

my ($color, $fruit) = @{$hoa->{keytwo}}{'color', 'fruit'};
[download]

If you go with arrays, why not use constants to speed things up slightly:

sub IDX_COLOR () { 0 }
sub IDX_FRUIT () { 1 }
my ($color, $fruit) = @{$hoa->{keytwo}}[IDX_COLOR, IDX_FRUIT];
[download]

or

use constant IDX_COLOR => 0;
use constant IDX_FRUIT => 1;
my ($color, $fruit) = @{$hoa->{keytwo}}[IDX_COLOR, IDX_FRUIT];
[download]

The combination of the empty prototype and the constant value being returned makes IDX_COLOR and IDX_FRUIT constants rather than functions.

Something like this ought to work:

my( $color, $fruit ) = @{$hoa->{keytwo}}[$idx_color, $idx_fruit];
[download]

There's nothing wrong with your use of a HoA. It is true, however, that a lot of thought should go into selecting the construction of complex datastructures. The right layout makes all the difference in code complexity/simplicity.

There's nothing wrong with your use of a HoA. It is true, however, that a lot of thought should go into selecting the construction of complex datastructures. The right layout makes all the difference in code complexity/simplicity.

This is even more true when you try creating an artificial neural network in pure perl...  :)  Except in NN's it is normally three, or more, levels deep (AoHoH, HoHoH, etc.) and the code to transverse such structures can get a little intresting.

I think that the line

my ($idx_color, $idx_fruit) = (0,1);
[download]

my $hoh =
  {
    keyone => { color => 'green',
                fruit => 'apple' },
    keytwo => { color => 'purple',
                fruit => 'plum' }
  };
[download]

my ( $color, $fruit ) = @{ $hoh->{ keytwo } }{ qw( color fruit ) };
[download]

my $aoh =
  [
    { color => 'green',  fruit => 'apple' },
    { color => 'purple', fruit => 'plum' },
  ];
my ( $color, $fruit ) = @{ $aoh->[ 1 ] }{ qw( color fruit ) };
[download]

my @fields = qw( color fruit );
my $aoh;

@{ $aoh->[ @$aoh ] }{ @fields } = @$_ for ( [ qw( green apple ) ],
                                            [ qw( purple plum ) ] );
[download]

And that, of course, brings you to OOP...which may be better or worse depending on your viewpoint :)

 package Fruit;

 sub new {
   my $class = shift;
   my $self = {};
   my $color = shift || '';
   my $name  = shift || '';
   bless $self, $class;

   $self->color( $color );
   $self->name( $name );

   return $self;
 }

 sub color { 
  my $self = shift; 
  $self->{color} = $_[0] if $_[0]; 
  return $self->{color};
 }

 sub name {
  my $self = shift;
  $self->{name} = $_[0] if $_[0];
  return $self->{name};
 }

 sub print {
   my $self = shift;
   print "I am just a ", $self->color(), " ", $self->name(), "\n";
 }

 1;

 package main;

 my $first_fruits = Fruit->new( 'green', 'apple' );
 my $second_fruits = Fruit->new( 'purple', 'plum' );
 
 my @fruit_basket = ( $first_fruits, $second_fruits );

 $second_fruits->print();
[download]

This is a fairly basic implementation, you can get as fancy as you'd like.

I think tlm is right, I should be using HOH here, so I will be doing a bit of code rewrite.

One disadvantage of HOH that occurs to me right away though, is if I mistype a key when setting a value in the hash, I don't get any type of error message. I often have autovivification errors that arise in this kind of way.

Is there any way to program defensively against this kind of error? One thing that occurs to me is I could just use the "functions as constants" thing that ikegami mentions earlier. Anyone else have other defense programming suggestions for dealing with this and autovivification with HOH?

Several of the replies to this node address the issue you bring up.

the lowliest monk

use warnings;
use strict;

my $hoa = {
    keyone => ["green","apple"],
    keytwo => ["purple","plum"]
};

my $p;
for (sort keys %$hoa) {
    $p = $hoa->{$_};
    print join ' ', @$p; print "\n";
}
[download]

    print join ' ', @$p[0], @$p[1]; print "\n";
[download]

    print join ' ', $p->[0], $p->[1]; print "\n";
[download]

for (sort keys %$hoa) {
    print join ' ', @{$hoa->{$_}}; print "\n";
}
[download]