Коя е най-добрата практика на Perl за връщане на хешове от функции?

Просто върнете препратката. Няма нужда да дереферирате целия хеш, както правите във вашите примери:

my $result = some_function_that_returns_a_hashref;
say "Foo is ", $result->{foo};
say $_, " => ", $result->{$_} for keys %$result;

и т.н.

Никога не съм виждал някой да предава празни препратки, за да задържи резултата. Това е Perl, не C.

Опитвайки се да създадете копия, като кажете

my %hash = %{$ref_hash};

е дори по-опасно от използването на hashref. Това е така, защото създава само плитко копие. Това ще ви накара да мислите, че е добре да промените хеша, но ако съдържа препратки, те ще променят оригиналната структура на данните. Смятам, че е по-добре просто да предавате препратки и да внимавате, но ако наистина искате да сте сигурни, че имате копие от предадената препратка, можете да кажете:

use Storable qw/dclone/;

my %hash = %{dclone $ref_hash};

Първият е по-добър:

my ($ref_array,$ref_hash) = $this->getData('input');

Причините са:

• във втория случай getData() трябва да провери структурите от данни, за да се увери, че са празни
• имате свободата да върнете undef като специална стойност
• изглежда по-идиоматично на Perl.

Забележка: линиите

@array = @{$ref_array};
%hash = %{$ref_hash};

са съмнителни, тъй като копирате повърхностно всички структури от данни тук. Можете да използвате препратки навсякъде, където имате нужда от масив/хеш, като използвате -> оператор за удобство.

ICommandService commandService = (ICommandService) PlatformUI.getWorkbench().getService(ICommandService.class);

final String commandId="org.eclipse.ui.edit.copy";
Command command = commandService.getCommand(commandId);
command.addCommandListener(new ICommandListener() {

    public void commandChanged (CommandEvent commandEvent) {
        System.out.println(">> Command changed: " + commandId);
    }
});

Ако става достатъчно сложно, че и сайтът за извикване, и извиканата функция плащат за това (защото трябва да мислите/пишете повече всеки път, когато го използвате), защо просто не използвате обект?

my $results = $this->getData('input');

$results->key_value_thingies;
$results->listy_thingies;

Ако създаването на обект е „твърде сложно“, тогава започнете да използвате Moose, така че вече да не е.

Моите лични предпочитания за подинтерфейси:

1. Ако рутината има 0-3 аргумента, те могат да бъдат предадени под формата на списък: foo( 'a', 12, [1,2,3] );
2. В противен случай подайте списък с двойки стойности на имена. foo( one => 'a', two => 12, three => [1,2,3] );
3. Ако рутината има или може да има повече от един аргумент, сериозно обмислете използването на двойки име/стойност.

Предаването на препратки увеличава риска от непреднамерена промяна на данните.

При връщания обикновено предпочитам да връщам списък с резултати, а не масив или препратка към хеш.

Връщам референции за хеш или масив, когато това ще направи забележимо подобрение в скоростта или потреблението на памет (т.е. ГОЛЕМИ структури), или когато е включена сложна структура от данни.

Връщането на препратки, когато не са необходими, лишава човек от възможността да се възползва от хубавите характеристики на Perl за обработка на списъци и го излага на опасностите от неволно модифициране на данни.

По-специално намирам за полезно да присвоя списък с резултати в масив и да върна масива, което предоставя контекстното поведение на връщане на масив към моите подчинени.

В случай на предаване на два хеша бих направил нещо като:

my $foo = foo( hash1 => \%hash1, hash2 => \%hash2 ); # gets number of items returned
my @foo = foo( hash1 => \%hash1, hash2 => \%hash2 ); # gets items returned

sub foo {
   my %arg = @_;

   # do stuff

   return @results;
}

Първоначално публикувах това към друг въпрос и след това някой посочи това като „свързана публикация“, така че ще го публикувам тук, за да си представя темата, ако приемем, че хората ще се сблъскат с нея в бъдеще.

Ще противореча на Приетия отговор и ще кажа, че предпочитам данните ми да бъдат върнати като обикновен хеш (добре, като списък с четен размер, който вероятно ще бъде интерпретиран като хеш). Работя в среда, в която сме склонни да правим неща като следния кодов фрагмент и е много по-лесно да комбинирате и сортирате, нарязвате и разделяте, когато не се налага да дереферирате всеки друг ред. (Също така е хубаво да знаете, че някой не може да повреди вашия hashref, защото сте предали цялото нещо по стойност - въпреки че някой посочи, че ако вашият хеш съдържа повече от прости скалари, това не е толкова просто.)

my %filtered_config_slice = 
   hashgrep { $a !~ /^apparent_/ && defined $b } (
   map { $_->build_config_slice(%some_params, some_other => 'param') } 
   ($self->partial_config_strategies, $other_config_strategy)
);

Това се доближава до нещо, което моят код може да направи: изграждане на конфигурация за обект, базиран на различни обекти на конфигурационна стратегия (някои от които обектът познава по същество, плюс някой допълнителен човек) и след това филтрира някои от тях като неподходящи.

(Да, имаме хубави инструменти като hashgrep и hashmap и lkeys, които правят полезни неща за хешовете. $a и $b се настройват съответно на ключа и стойността на всеки елемент в списъка). (Да, имаме хора, които могат да програмират на това ниво. Наемането е неприятно, но имаме качествен продукт.)

Ако не възнамерявате да правите нещо подобно на функционално програмиране като това или ако имате нужда от повече производителност (профилирали ли сте?), тогава със сигурност използвайте hashrefs.

Ъъъ... "преминаването на хешовете може да се извърши само чрез препратка"?

sub foo(%) {
    my %hash = @_;
    do_stuff_with(%hash);
}

my %hash = (a => 1, b => 2);
foo(%hash);

какво ми липсва

Бих казал, че ако проблемът е, че трябва да имате няколко изхода от функция, по-добре е като обща практика да изведете структура от данни, вероятно хеш, която съдържа всичко, което трябва да изпратите, вместо да приемате модифицируеми препратки като аргументи .