I don't see why. You have to choose a method name that the non-AutoDB objects do not use anyway, otherwise their method gets called during the deserialization and mess things up. If you choose a name that none of the objects use they will not notice you injected a new method into their space.

Let's assume you want to use the name "_thaw". Your AutoDB objects define their own _thaw() method and do whatever's necessary after the deserialization. And they do it in the way expected by Data::Dumper. Apart from this you have a class that knows nothing about AutoDB or Data::Dumper, but defines a _thaw() method. That method is not supposed to be called after deserialization, it does not return the revived object, it does something you don't really be done at that time. In this case you run into problems no matter when do you check for the _thaw() method's existence. Whether you use your modified Data::Dumper or whether you define a default _thaw(), Data::Dumper calls the object's _thaw() method and thigs get messed up.

The only case when the behaviour differs is if the _thaw() method is not defined when serializing and is when deserializing. While this may seem like a minor unimportant thing it actually is not. Suppose a class does not need to do anything special upon deserialization, therefore it does not contain _thaw(), you serialize some data structure containing objects of that class and store them in the database. Then a year later you extend the class and it now needs to do something after deserialization so you do define a _thaw() method. Now with your modified Data::Dumper the old exports do not call the _thaw(), new exports do. Things break. With my proposal the _thaw() defined in the class overloads the default from UNIVERSAL and the right _thaw() gets called both for old and new exports.

You might actually use the _thaw() method not only to reopen database or socked connections and stuff like that, you may also use it to "upgrade" the object. If you change the internal layout of a class or just add some new fields you may want/need to initialize the new fields or convert the deserialized data.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

In reply to Re^5: socio-political guidance sought by Jenda
in thread socio-political guidance sought by Anonymous Monk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.