Should I choose a hash, an object or an array to r

问题:

I was always wondering about this, but never really looked thoroughly into it.

The situation is like this: I have a relatively large set of data instances. Each instance has the same set or properties, e.g:

# a child instance
name
age
height
weight
hair_color
favorite_color
list_of_hobbies

Usually I would represent a child as a hash and keep all children together in a hash of hashes (or an array of hashes).

What always bothered me with this approach is that I don't really use the fact that all children (inner hashes) have the same structure. It seems like it might be wasteful memory-wise if the data is really large, so if every inner hash is stored from scratch it seems that the names of the key names can take far more sapce than the data itself... Also note that when I build such data structures I often nstore them to disk.

I wonder if creating a child object makes more sense in that perspective, even though I don't really need OO. Will it be more compact? Will it be faster to query?

Or perhaps representing each child as an array makes sense? e.g.:

my ($name, $age, $height, $weight, $hair_color, $favorite_color, $list_of_hobbies) = 0..7; 
my $children_h = {
  James => ["James", 12, 1.62, 73, "dark brown", "blue", ["playing football", "eating ice-cream"]], 
  Norah => [...], 
  Billy => [...]
};
print "James height is $children_h->{James}[$height]\n";

Recall my main concerns are space efficiency (RAM or disk when stored), time efficiency (i.e. loading a stored data-set then getting the value of property x from instance y) and ... convenience (code readability etc.).

Thanks!

回答1:

1. Perl is smart enough to share keys among hashes. If you have 100,000 hashes with the same five keys, perl stores those five strings once, and references to them a hundred thousand times. Worrying about the space efficiency is not worth your time.

2. Hash-based objects are the most common kind and the easiest to work with, so you should use them unless you have a damn good reason not to.

3. You should save yourself a lot of trouble, start using Moose, and stop worrying about the internals of your objects (although, just between you and me, Moose objects are hash-based unless you use special extensions to make them otherwise -- and once again, you shouldn't do that without a really good reason.)

回答2:

I guess it is mainly personal taste (except of course when other people have to work on your code too) Anyway, I think you should look into moose It is definitely not the most time nor space efficient, but it is the most pleasant and most secure way of working. (By secure, I mean that other people that use your object can't misuse it as easily)

I personally prefer an object when I'm really representing something. And when I work with objects in perl, I prefer moose

Gr, ldx

回答3:

Unless absolute speed tuning is a requirement, I would make an object using Moose. For pure speed, use constant indexes and an array.

I like objects because they reduce the mental effort needed to work with big deep structures. For example, if you build a data structure to represent the various classrooms in a school. You'll have something like a list of kids, a teacher and a room number. If you have everything in a big structure you have to know the structure internals access the hobbies of the children in the classroom. With objects, you can do somthing like:

my @all_hobbies = uniq map $_->all_hobbies, 
                       map $_->all_students, $school->all_classrooms;

I don't care about the internals. And I can concisely generate a unique list of all the kids hobbies. All the complicated accesses are still happening, but I don't need to worry about what is happening. I can simply use the interface.

Here's a Moose version of your child class. I set up the hobbies attribute to use the array trait, so we get a bunch of methods simply for the asking.

package Child;

use Moose;

has [ 'name', 'hair_color', 'fav_color' ] => (
    is => 'ro',
    isa => 'Str',
    required => 1,
);

has [ 'age', 'height', 'weight' ] => (
    is => 'ro',
    isa => 'Num',
    required => 1,
);

has hobbies => (
    is      => 'ro',
    isa     => 'Int',
    default => sub {[]},
    traits  => ['Array'],
    handles   => {
        has_no_hobbies => 'is_empty',
        num_hobbies    => 'count',
        has_hobbies    => 'count',
        add_hobby      => 'push',
        clear_hobbies  => 'clear',
        all_hobbies    => 'elements',
    },
);

# Good to do these, see moose best practices manual.
__PACKAGE__->meta->make_immutable;
no Moose;

Now to use the Child class:

use List::MoreUtils qw( zip );

# Bit of messing about to make array based child data into objects;

@attributes = qw( name age height weight hair_color fav_color hobbies );

my @children = map Child->new( %$_ ),
               map { zip @attributes, @$_ }, 
    ["James", 12, 1.62, 73, "dark brown", "blue",  ["playing football", "eating ice-cream"]], 
    ["Norah", 13, 1.75, 81, "black",      "red",   ["computer programming"]],
    ["Billy", 11, 1.31, 63, "red",        "green", ["reading", "drawing"]], 
;


# Now index by name:

my %children_by_name = map { $_->name, $_ } @children;

# Here we get kids with hobbies and print them.

for my $c ( grep $_->has_hobbies, @children ) {
    my $n = $c->name;
    my $h = join ", ", $c->all_hobbies;
    print "$n likes $h\n";
}

回答4:

I usually start with a hash and manipulate that, until I find instances where the data I really want is derived from the data that I have. And/or that I want some sort of peculiar--or even polymorphic--behavior.

At that point, I start creating a packages to store class behavior, implementing methods as needed.

Another case is where I think this data would be useful in more than one instance. In that case, it's either rewrite all the selection cases everywhere where you think you'll need it or package the behavior in a class, so that you don't have to do too much copying or studying of the cases the next time you want to use that data.

回答5:

Generally, if you don't need utter efficiency, hashes will be your best bet. In Perl an object is just a $something with a class name attached. The object can be a hash, an array, a scalar, a code reference, or even a glob reference inside. So objects can only possibly be a win in convenience, not efficiency.

If you want to give an array a shot, the typical way of making that somewhat maintainable is using constants for the field names:

use strict;
use warnings;
use constant {
  NAME            => 0,
  AGE             => 1,
  HEIGHT          => 2,
  WEIGHT          => 3,
  HAIR_COLOR      => 4,
  FAVORITE_COLOR  => 5,
  LIST_OF_HOBBIES => 6,
};

my $struct = ["James", 12, 1.62, 73, "dark brown", "blue", ["playing football", "eating ice-cream"]];

# And then access it with the constants as index:
print $struct->[NAME], "\n";
$struct->[AGE]++; # happy birthday!

Alternatively, you could try whether using an array (object) as follows makes more sense:

package MyStruct;
use strict;
use warnings;
use Class::XSAccessor::Array
  accessors => {
    name => 0,
    age => 1,
    height => 2,
    weight => 3,
    hair_color => 4,
    favorite_color => 5,
    list_of_hobbies => 6,
  };

sub new {
  my $class = shift;
  return bless([@_] => $class);
}

package main;
my $s = MyStruct->new;
$s->name("James");
$s->age(12);
$s->height(1.62);
$s->weight(73);
# ... you get the drill, but take care: The following is fine:
$s->list_of_hobbies(["foo", "bar"]);
# This can produce action-at-a-distance:
my $hobbies = ["foo", "bar"];
$s->list_of_hobbies($hobbies);
$hobbies->[1] = "baz"; # $s changed, too (due to reference)

Coming back to my original point: Usually, you want hashes or hash-based objects.

回答6:

Whenever I try to decide between using a hash or an array to store data, I almost always use a hash. I can almost always find a useful way to index the values in the list for quick lookup. However, your question is more about hashes of array refs vs hashes of hash refs vs hashes of object refs.

In your example above, I would have used a hash of hash refs rather than a hash of array refs. The only time I would use an array is when there is an inherent order in the data that should be maintained, that way I can look things up in order. In this case, there isn't really any inherent order in the arrays you're storing (e.g., you arbitrarily chose height before weight), so it would be more appropriate (in my humble opinion) to store the data as a hash where the keys are descriptions of the data you're storing (name, height, weight, etc).

As to whether you should use a hash of hash refs or a hash of object refs, that can often be a matter of preference. There is some overhead associated with object-oriented Perl, so I try only to use it when I can get a large benefit in, say, usability. I usually only use objects/classes when there are actions inherently associated with the data (so I can write $my_obj->fix(); rather than fix($my_obj);). If you're just storing data, I would say stick with a hash.

There should not be a significant difference in RAM usage or in time to read from/write to disk. In terms of readability, I think you will get a huge benefit using hashes over arrays, since with the hashes the keys actually make sense, but the arrays are just indexed by numbers that have no real relationship with the data. This may require more disk space for storage if you're storing in plain text, but if that's a huge concern you can always compress the data!