Pourquoi devrais-je retourner une table de hachage ou d'un hachage de référence en Perl?

Pourquoi ne pas retourner à la fois? Le contexte est une fonctionnalité très puissante en Perl pour permettre à vos fonctions de "faire ce que tu veux dire". Souvent, la décision de ce qui est une meilleure valeur de retour dépend de la façon dont le code appelant les plans de l'utilisation de la valeur, ce qui est exactement pourquoi Perl a la builtin wantarray.

sub build_hash {
    my %hash;
    @hash{@keys} = (1) x @keys;
    wantarray ? %hash : \%hash
}

my %hash = build_hash;  # list context, a list of (key => value) pairs
my $href = build_hash;  # scalar context, a hash reference

OriginalL'auteur Eric Strom

Ce que vous cherchez est un de hachage tranche:

# assigns the value 1 to every element of the hash

my %hash;                                   # declare an empty hash
my @list = qw(hi bi no th xc ul 8e r);      # declare the keys as a list
@hash{@list} =                              # for every key listed in @list,
                (1) x @list;                # ...assign to it the corresponding value in this list
                                            # which is (1, 1, 1, 1, 1...)  (@list in scalar context
                                            #   gives the number of elements in the list)

La x opérateur est décrit à perldoc perlop.

Voir perldoc perldsc et perldoc perlreftut des tutoriels sur des structures de données et de références (les deux doivent-lit pour les débutants comme les experts). Hachage tranches eux-mêmes sont mentionnés dans perldoc perldata.

Au sujet de son retour d'un hachage à partir d'une fonction, normalement vous devez retourner le hachage de lui-même, pas une référence. Vous pouvez utiliser une référence si le hachage est énorme et à la mémoire ou le temps est une préoccupation, mais qui ne devrait pas être votre premier souci: le code de travail est.

Les valeurs de retour des fonctions sont toujours des listes (d'où le retour d'un scalaire est essentiellement une liste d'un élément). Les hachages sont des listes en Perl: Vous pouvez attribuer l'une à l'autre interchangably (en supposant que la liste a un même nombre d'éléments, et il n'y a pas de clé de collisions qui ferait en sorte que certaines valeurs perdues lors de la conversion):

use strict; use warnings;
use Data::Dumper;

function foo
{
    return qw(key1 value1 key2 value2);
}

my @list = foo();
my %hash = foo();

print Dumper(\@list);
print Dumper(\%hash);

donne:

$VAR1 = [
          'key1',
          'value1',
          'key2',
          'value2'
        ];

$VAR1 = {
          'key2' => 'value2',
          'key1' => 'value1'
        };

PS. Je recommande fortement l'écriture de petits programmes exemples comme celui ci-dessus pour jouer avec des structures de données et de voir ce qui se passe. Vous pouvez apprendre beaucoup de l'expérimentation de la!

OriginalL'auteur Ether

Je vais aller à contre courant et ce que tout le monde est en train de dire, et de dire que je préfère avoir mes données retourné comme une table de hachage (eh bien, comme une même taille de la liste qui est susceptible d'être interprétée comme une table de hachage). Je travaille dans un environnement où nous avons tendance à faire des choses comme l'extrait de code suivant, et il est beaucoup plus facile de combiner et de les trier et de tranche et dés lorsque vous n'avez pas de déréférencement de chaque autre ligne. (Il est également agréable de savoir que quelqu'un ne peut pas endommager votre hashref parce que vous avez passé toute chose de valeur. edit: sauf si vous avez des références à d'autres objets/hachages/tableaux dans la table de hachage, les valeurs, alors que vous êtes en difficulté de toute façon).

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)
);

Cela se rapproche de quelque chose que mon code peut faire: la construction d'une configuration d'un objet en fonction de divers configuration de la stratégie objets (dont certains que l'objet sait à propos de soi, plus l'homme) et le filtre puis certains d'entre eux comme hors de propos.

(Oui, nous avons beau des outils comme hashgrep et hashmap et lkeys que faire des choses utiles pour les tables de hachage. $a et $b, se mettre à la clé et la valeur de chaque élément dans la liste, respectivement). (Oui, nous avons des gens qui peuvent le programme à ce niveau. La location est odieux, mais nous avons un produit de qualité.)

Si vous n'avez pas l'intention de faire quelque chose comme cela ressemble à de la programmation fonctionnelle, ou si vous avez besoin de plus de performance (avez-vous profiler?) alors bien sûr, l'utilisation hashrefs.

OriginalL'auteur fennec

Prendre soin: a.pl renvoie une liste avec un même nombre d'éléments, pas une table de hachage. Lorsque vous affectez ensuite cette liste à un hachage de la variable, la valeur de hachage sera construit avec les éléments à la même indices que les clés et les éléments à l'étrange indices des valeurs. [EDIT: C'est la façon dont j'ai toujours vu la question, mais sub { ... %hash } effectivement se comporte un peu différemment sub { ... @list }. ]

Pour la même raison, la construction d'une table de hachage, la façon dont vous décrivez, est aussi simple que:

my %hash = map { $_ => 1 } qw(hi bi no th xc ul 8e r);

Ma règle personnelle de base est d'éviter de faire référence, à moins que j'ai vraiment besoin d'eux (par exemple, structures imbriquées, ou lorsque vous avez vraiment besoin de passer une référence à la même chose).

EDIT: (je ne peux pas cliquer sur "ajouter un commentaire" lien plus?! Utilisez les touches souris ici...)
J'ai réfléchi un peu et je pense que de passage autour de hachage refs est probablement mieux après tout, en raison de la façon dont nous utilisons une table de hachage. Le paragraphe ci-dessus tient toujours pour tableau réf.

Merci pour vos commentaires Schwern et de l'Éther.

OriginalL'auteur Inshallah