Remember that, in Perl, your subroutine arguments are an array. If bar will never take any other options, then there is no reason to pass in an arrayref unless you have other uses for the same array and need to avoid building it again, or if you really need for bar to change an array in its caller.

Your scenarios are not quite equivalent. In scenario 1, calling bar changes the value of @arr in foo. In scenario 2, bar constructs its own array rather than changing one of foo's lexicals. In both of these, zzz must be careful not to change its argument, or it will change either @arr in foo (scenario 1) or @array in bar (scenario 2).

Generally, this kind of close coupling is a fertile source of strange bugs and should be avoided unless performance is so critical that avoiding the overhead of building new arrays is needed or passing results back by modifying arguments is absolutely necessary.

This pattern is common in C, but in Perl your return value can also be an array (or something very close to one), so modifying arguments is generally unnecessary and should be avoided (except of course for $self in object methods that specifically exist to mutate an object).

Thanks for your feedback...

my $array_ref = {};
push(@$array_ref, {});
[download]

use strict;
use warnings;

sub foo {
    my %hash = ();
    ....
    %hash = ....  # key/values populated by some API

    bar(\%hash);
}

sub bar {
    my $hash_ref = shift;
    my @arr_of_href = $hash_ref;
    
    foreach my $i (.....) {
       ....  %some_hash initialized here for each iteration of the for
+ loop
       push (@arr_of_href, \%some_hash); 
    }

    zzz(\@arr_of_href);   # zzz() will do something with this array
}
[download]

sorry about the incorrect usage; i've corrected the code snippet.

G'day andrewkl,

Welcome to the Monastery.

I think you're looking at this back-to-front.

Write your subroutines such that they read the arguments they need. E.g.

sub f {
    my ($AoH) = @_;

    for my $hashref (@$AoH) {
        # do something with $hashref
    }
}
[download]

Then call those subroutines with the appropriate arguments. E.g.

...
# somewhere in your code
f($AoH);
...
# elsewhere in your code
f([$hashref1, $hashref2]);
...
# and at some other point
f([\%hash]);
...
[download]

As you can see from those examples, you can (often) create the argument list in situ.

What you really want to avoid is subroutine definitions like this:

sub g {
    my ($arrayref_containing_just_one_hashref) = @_;
    my $hashref = $arrayref_containing_just_one_hashref->[0];
    # do something with $hashref
}
[download]

So, get the subroutine definition right, then call as needed. If that requires some complex code to create the argument list, so be it.

Thank you for your feedback...
I'm having a discussion with a colleague. She prefers scenario 1 whereas i think scenario 2 makes more sense.

When you write the code that calls the sub which version is easiest to understand when you or someone else reads the code in a month or more? Use that version. Almost always there is nothing else that matters.

The two alternatives are not equivalent, so choose whichever matches most closely to the useful parameters of your function.

Hi,
I guess my question is: Does it make sense to pass in an array that contains only one item (a ref to a hash). That array will always have only 1 item.

Or is it better to directly pass in the hash array (Scenario 2)

Thanks
--Andrew

Will the subroutine ever be expected to perform its task on a list of hashes? Then an array would make sense. Otherwise it seems a needless complication. Which is repeating what I said before. It's your subroutine; YOU figure out how you want to use it.

Dum Spiro Spero