Array versus hash isn't an issue if you ask me. The penalty you pay for constants is probably larger than those for a hash lookup. Constants are really subroutines, and subroutine calls use the stack.
The advantage of array-based objects, as far as I can tell, is reduced memory usage. You are only storing data and not hash-keys. They are faster, in theory, it would seem, but not in practice. If you used
Filter instead of
constant, then I might agree. A small compile-time penalty for a large run-time improvement. Another alternative, although a bit
bold, is to use pseudo-hashes.
Hash-based structures are fully extensible, and can be sub-classed easily. I don't think the same holds true for the array-based ones. How do you know where the parent left off, index wise? Do you have to keep track with another constant?
All of this is speculation, of course, until some testing is done to see if it is true.
One thing I would like to do is take something like
Autoload::Hash and extend it into a module which could fully realize the benefits of the array-based object (speed, memory) without requiring more code maintenance. Automatic code generation means referential integrity.