Inside Out object do have limitations of sometimes being inconvenient for you as a user, but you as the maintainer can minimize those inconveniences by providing methods to dump the object, etc.
Perhaps more importantly for large systems, though, is the fact that method accessors can impose a performance hit by requiring the method call (as opposed to the hash look-up). So make sure that your accessors are well optimized in these situations.
If you have massive amounts of code that treat your objects as hashes and you don't want to refactor all of that code, you could look at refactoring your object to actually have a hash-based interface, but do method calls internallys. Lookups to non-existant "hash keys" could throw an exception. Take a look at the internals Regexp::Common (if you can follow it). It basically provides a nested hash interface, but each level of nesting acts both as a string (returns a pattern) and as a hash ref for deeper nesting. Rather cool. This could let you provide a strict "hash-like" interface to your objects.
In reply to Re^2: Using the strict module in object oriented programming
by Codon
in thread Using the strict module in object oriented programming
by mrguy123
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |