in reply to
Re^2: A different OO approach
in thread A different OO approach
I don't see keeping @USED in sync a problem. It's a fairly simple thing to do, and if you use a function generator to make your accessors, then you really can't forget.
I'm not saying a base class doesn't have any merit, but what about everthing that already exists on CPAN? How would this play with them? Ideally, I shouldn't have to know the internals of a base class if I want to inherit from it.
Most freezing and thawing is done with a handful of modules, patching those modules to look for a certain method before serializing would let someone inherit from these "inside out" modules in a fairly transparent fashion, regardless of whether the inheriting class used a common "base" module or not. In fact the descendant wouldn't have to know or care how the object was implemented. To it, it would work pretty much like any other hash based object. The Serialization routine could just return the appropriate data blessed into a helper class. The helper class when accessed through a method, could turn itself into a proper "inside out" object.
The other thought would be using a HoHoH as you do, would probably be at least 30% slower than Abigail-IIs method of just using lexical hashes. For many things, speed is not a priority, but for objects that will be called often (parsers, tokenizers, etc) this could be a big hit. So my main argument would be that if it would interfere with using other modules in a transparent fashion, I think it would be of limited value in the general case.
"To be civilized is to deny one's nature."