The serialization is a larger problem. I don't like the idea of everyone having to agree on a standard way of doing things to get the benefits of prior work. (This is Perl after all.) There are hooks in Data::Dumper and Storable, for serialization, it seems to me, that it might make better sense to provide a serialization hook instead. (Though getting the modules to recognize this from subclasses is another issue. Perhaps a patch to Dumper that looks for a Freezer method automatically if the class isa Dumper. (Same for Storable). Seems like it would be easier to patch the few main serialization modules then every other module on CPAN that you may want to inherit from.

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.

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 stupid. If I have to do some monkey coding then at some point I will forget to do it properly. It also offends my sense of once and only once.

I can move attributes around classes a lot during refactoring and, for me, it's asking for trouble. If the perl can do it, it should do it :-)

I like this solution and, as you say, building it into a function generator or similar solves the problem nicely.

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.

Ah. I see what you're getting at. Good point.

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.

I agree completely - but it's not my proposal. You confuse me with fruiture - it's his RFC ;-)