On Mon, Mar 2, 2009 at 10:09 AM, Eric Wilhelm <enoba...@gmail.com> wrote:
> # from Joshua ben Jore > # on Monday 02 March 2009 08:20: > > >If you redesigned, replacing your hash with an array would be harder > >to typo, faster, smaller, not as nice to dump with Dumper, and harder > >for 3rd parties to extend. > > Is "harder to extend" a design goal? You also make it harder to use. I don't see how harder to extend could be considered a benefit - I think he meant that to show that there is a trade-off involved. And if everybody did it, you would have name clashes with all of those > constants. That's why Perl has packages. Client code should be using accessor methods so the constants are only needed in the object class package. > Using methods for typo protection doesn't get you compile-time checking, > but you have tests, right? You get runtime checking, though. At least it doesn't just give a surprise undef for misspelling something. Personally I always use hashes for objects. Hashes are pretty fast in Perl, especially when there aren't many keys, so I don't think the benefits of using arrays are worth it. The risk of typos is pretty small, and the ability to easily extend it is a big plus. I provide accessor methods and don't like users prying around in the internal hash keys but if they are willing to take the risk I don't see that it's my place to stop them, either.