As a quick browse of the CPAN will confirm, Perl programmers seem to
prefer to use hashes for storing the state of their objects. There
are many possible explanations for this preference, but it is most
likely that hashes' appeal stem from the fact that the programmer can
give hash elements nice, intuitive names. Despite this attractive
flexibility, there are some problems. Hashes do not offer any sort
of collision protection (i.e., two separate classes using the same key
in a hash to store different information). Consider also that if a
programmer accidentally misspells a key name, he could find himself
on the trail of a very elusive bug. Hashes offer no protection against
misspelled key names, and it would be very nice if such a typo were a
compile time error. Finally, we could also do better than hashes in
terms of performance: hashes have slower access times and use more
memory than Perl's other aggregate type, arrays.
In this talk, I will describe a technique that allows us to take
advantage of the performance benefits offered by arrays without losing
the ability to give elements intuitive names. This technique will
also provide collision insurance and cause a compile time error if the
programmer happens to misspell a key name, provided that the strict
pragma is in use--so the technique also encourages nicer style.
![[yapc 99 talks]](y_t.jpg)