I have no problem with the idea of dumping state as a means of debugging.

I also have no problem with the idea of dumping structure as a mechanism for learning, reference, or debugging.

Where it all goes wrong (for me) is the idea of using dumping as a mechanism for saving and restoring state, which is where I would argue that "dumping" transitions to "serialisation". This is doubley bad (IMO) if the form that the serialisation takes is that of generating evalable entities.

To me, the purposes of serialisation (as opposed to dumping) are twofold--persistance & Interchange.

The problems I see with doing either of these from the outside of the objects are.

1. Persistance.

   If an object is in anything other than a simple one level , non-composite (either through is-a or has-a), then storing a complete object with all it's superclass attributes and those of any instances of objects that it has as attributes is illogical.

   If I extend an existing class to add some new attributes, when I come to Persist that new class, I don't want to have to modify the existing stored instances nor modify existing applications that use those instances.

   Assuming a RDBMS is used for storage, better to create a new table for the new attributes and have a foriegn key on the existing table, then create a view to join the two tables for use by the new class, than have to modify the existing table. If I ask the object to persist itself and it calls superclass to persist itself. The superclass instance saves itself in its original table and returns is Primary key ID. Then the subclass instance saves its attributes including the returned key(s) in its own table and the job is done.

   If I attempt this from the outside, then the I get one almighty morass of mixed up data and either need to store it as a single entity, which doesn't make sense if there is any chance of two subclass instance sharing a superclass instance. Or I need to parse the returned monolith to seperate out the parts.

   Add in to this the idea that two Employee instances may share the same Address, or two Urls the same IP etc.

2. Interchange.

   Even interchangeing evalable datastructures between two Perl applications or sites can be fraught with problems. Whilst Storable can nFreeze to and thaw through network ordering, if the source is 64-bit and the destination 32-bit...?

   Or if one site is dependant upon a downlevel verson of perl that doesn't understand something generated by a newer level.

   As soon as you need to interchange the data between different languages, evalable serialisation makes no sense at all. Better again to have the objects themselves produce a standardized interchange format. The obvious one these days is XML. Each object knows it's own structure and can easily produce this. Superclasses just embed the returned XML from the subclasses into their own representation. Receiving application can simply ignore those attributes it is not interested in.

That's why I think that serialisation should be done from the inside not externally. Once an instance has that ability, dumping can simply use this. I'd rather read an XML representation of a deeeply nested structure than the output from Data::Dumper I think.

From the pure dumpability point of view, I actually think that Abigail's version of IO objects is better than the standard hash model in as much as I can build in a class method that dumps the entire class' instances and if the class is subclassed two or more times, the bless'd ref keys in the attribute hashes tell me which superclass was involved in the creation of each instance, which I already found useful as a debugging aid.

Again this requires adding to and invoking from the class, but I think that it is a small price to pay in terms of development of reusable code.