I have found one circumstance where inside-out objects are required: when you have overloaded the dereferencing operator for the data type which implements you object. For Data::Postponed, I overloaded every dereferencing operator and no longer had any way to access the contents of my object.

I haven't worked with any of the caching modules, so I'm curious to understand what the underlying issues are. If the object can be serialized, it can be cached, no? Is it just that it's easy to throw a hash-based object at the caching modules for serialization? Whereas with an inside-out object, you'd have to explicitly write freeze/thaw routines?

It also occurs to me that it may depend on how you construct the inside-out class. To perrin's point -- you may not want to use inside-out classes for this. Some of the typical benefits of inside out classes include

• Strong encapsulation of data
• Ability to subclass any other class (e.g. written by someone else) without tight coupling to the underlying nature of the class

If you're caching, you're sort of explictly breaking encapsulation anyway for the purpose of efficiency, so unless the second point is important you may not need them..

On the other hand, there's no reason why you can't write an inside-out class that uses the blessed reference as the key to a hash with the value being a hash-reference containing the data. (Like a regular hash-based class, but with an extra level of indirection.) That preserves the ability to subclass anything and mostly keeps the strong encapsulation. It might then be easier/faster to write up a freeze/thaw routine to manipulate that underlying hash. (At which point you break encapsulation, but only via a class freeze/thaw routine.)

Is it just that it's easy to throw a hash-based object at the caching modules for serialization? Whereas with an inside-out object, you'd have to explicitly write freeze/thaw routines?

Yes. In theory, you could add something to Class::Std that works with Storable's hooks, but I don't think it's there already.