Why use arrays for objects instead of hashes ?

First: speed. In my benchmarks on a few boxes around here I've seen arrays be faster by 30%. I must admit that my benchmarks weren't perfect as I wasn't all that interested in speed per se, only in knowing whether I was to take a serious performance hit or not (I was nevertheless pleasantly surprised to note the opposite, it can't hurt).

Second: memory. Memory was much more important to me as I was targeting a mod_perl environment where every bit of memory tends to count. Depending on how they are used, arrays use from 30% up to 65% less space than hashes. As a rule of thumb the more keys you have, the more you may save.

It must be said though that despite the fact that I happened to be looking for ways to save space, it's not a reason to jump into array based objects and start converting every single hash you have to an array. Yes, I did see some of my processes lose ~3Mo of unshared memory so there are definitely cases when it's useful. Such cases are usually when you have lots of objects and/or structures that are fairly similar in nature (ie have the same keys) but contain different values. I don't know how Perl works internally but it would seem only logical that it has to store the keys with every hash, whereas using arrays there are no keys (which is why this package exists: to provide you with something that looks like keys into arrays).

In addition to that, this package can be seen as twisting slightly the view on how to do OO in Perl, encouraging some limited encapsulation of fields and extension subclassing rather than override subclassing (the latter really being a matter of taste).

Why not pseudo-hashes ?

Why Class::ArrayObjects ?

Its main advantage over "constant" (imho of course) is that you don't have to define the value of each field. Less typing, more readability.

"enum" also provides that plus but it enforces naming rules in a way which I find limiting (it probably has very good reasons to do so, but I think that they don't apply in the context of array based objects). This module only complains if you try to use a field name that isn't a valid Perl sub name. (Note: right now it doesn't even complain because I was convinced when I wrote it that Perl would. But it turns out that you are perfectly allowed to define a sub with a forbidden name. Whether this is a bug or a feature, I don't know).

And last but not least, it defines a way to allow for inheritance while using array based objects. A major drawback of array based objects is that unlike with hashes, if your base class adds a field, you have to move all your fields' indices up by one. You shouldn't have to know such things, or even to care about it.

Here, instead of using the "define" option (which creates fields in a class), simply use the "extend" option. Tell it which class to extend (it needs to be already loaded, and must use Class::ArrayObjects to define its fields too) and which fields to add. Class::ArrayObjects takes care of counting from the right index in your subclass. It can't do multiple inheritance, and unless someone hacks it in somehow I doubt it ever will.

You may use the "import" option to require that your parents' fields be defined in your own package too, so that you can access them. It is off by default so that you can use fields with the same names as those of your superclasse(s) (which is a plus over hash based objects) and also to avoid defining subs all over your package without you knowing about them.

It may be worth noting that the added functionality doesn't get in the way, and using this to define constants is just as fast as using "constant" or "enum".

The define option

  package Some::Class;
  use Class::ArrayObjects define => {
                                      fields  => [qw(_foo_ _bar_ BAZ)],
                                    };

"define" has only one option: "fields". It is an arrayref of strings which are the names of the fields you wish to use. They can be anything, so long as they are valid Perl sub names.

The extend option

  package Other::Class;
  use base 'Some::Class';
  use Class::ArrayObjects extend => {
                                      class   => 'Some::Class',
                                      with    => [qw(_zorg_ _fnord_ BEZ)],
                                      import  => 1,
                                    };

"extend" has three options:

• class

  This defines the class to extend (it must also use Class::ArrayObjects and have been loaded previously). If that class is not specified, it will look at @ISA. If @ISA contains only one item it will use that one.

• with

  This is exactly equivalent to "fields" except that it reads better to have extend class Foo with x,y,z.

• import

  Defaulting to false, setting it to any true value will make your superclasses' fields also defined in your package. This can be needed at times, though I wouldn't encourage its use.

After that ?

  package Some::Class;
  use Class::ArrayObjects define => {
                                      fields  => [qw(_foo_ _bar_ BAZ)],
                                    };

  my @arry = qw(zorg stuff blurp);
  print $arry[_bar_]; # stuff

Any operation you can do on arrays with numeric indices works exactly the same way. The only difference is that you are using names, which are much easier to remember. There is no performance penalty for this, Perl is smart enough to inline the return values of constant subs so that when in the above example you say _bar_ it really sees 1.

A note to mod_perl users

You can preload this module without defining any fields as follows:

  use Class::ArrayObjects qw();

In that case, "import()" will not be called and nothing will happen other then the preloading of the code. As a precaution, even if it were called it would return immediately.

I do recommend that you preload all modules that are based on Class::ArrayObjects so that the data it stores internally about which fields belong to which classes (in order to allow for extension) remains shared by all the processes.