And just to throw my hat in the ring in favor of inside-out objects, I liked 'em when I first saw 'em, then I saw issues with serialization, destruction, threading, debugging, and so on. Unfortunately, I've been spoiled with a couple of years of working with really strong programmers. Then I move to a codebase with lots of crufty inherited code and programmers trying to work with this and I've completely changed my mind about inside-out objects. I strongly recommend them.

... then I saw issues with serialization, destruction, threading, ...

Object::InsideOut takes care of all these issues for you.

---

Remember: There's always one more bug.

Secondly you can take a look at Inside-Out Objects

Ick. No offense, but that's a really outdated reference on the subject. My scratchpad has a section "Object-Oriented Perl - Inside-Out Technique" that has a more comprehensive set of Perlmonks posts on inside-out objects. For an even more comprehensive treatment, my YAPC::NA inside-out tutorial slides are online.

My scratchpad has a section "Object-Oriented Perl - Inside-Out Technique"

Please do not point to your scratchpad in nodes. A scratchpad is not an official place for publication, it can change any time you like and there's nothing we can do about it, actually, it is intended to be changed at will.

If you really feel your stuff is worth our while, for making it public in a permanent way, then publicize it somewhere more permanent. Like, here. Why point to your scratchpad, if you can just copy the relevant contents?

Why point to your scratchpad, if you can just copy the relevant contents?

Because I use my scratchpad as a categorized index that I change at will so it is up to date. Why litter nodes with reference lists that will be out of date the next time I update my index? :-)

But, since you asked so nicely...

Object-Oriented Perl - Inside-Out Technique

• Re: Where/When is OO useful?
• Re: Tutorial: Introduction to Object-Oriented Programming
• A different OO approach
• Yet Another Perl Object Model (Inside Out Objects)
• Class::InsideOut - yet another riff on inside out objects.
• Threads and fork and CLONE, oh my!
• inside-out objects using arrays?
• Array-based Inside-out Objects with Object::InsideOut
• How to use Inheritance with Inside-Out Classes and Hash Based Classes
• Inside-out objects inheriting from hash-based classes
• Seeking inside-out object implementations
• Anti-inside-out-object-ism
• Overriding bless for inside-out object safety
• Introducing Class::InsideOut

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

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.