Re^4: socio-political guidance sought

Thanks for the optimization, I'll use it for the Dumper.pm patch.

> The problem is that this tests for the Toaster method while the data is serialized/exported, not while it's deserialized/imported.

This is true, but for my purposes, this is better. Since the serialized string is being inserted into the database, I don't want it to have the thaw method associated with it unless it has a thaw method (justification: its misleading to the user)

> but I think the easiest solution is to define
> sub UNIVERSAL::Toaster { $_[0] }

ahh, but I don't have control over any non-AutoDB objects (I can't inject any methods into their space). Non-AutoDB objects are persisted only because they are pointed to by AutoDB objects (DD happily recurses over all references and builds a structure). But they have no ancestral connection to AutoDB.

Thus, this method won't work for me :(

Comment on Re^4: socio-political guidance sought

Replies are listed 'Best First'.
Re^5: socio-political guidance sought by Jenda (Abbot) on Aug 21, 2004 at 21:28 UTC
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	[reply]

Replies are listed 'Best First'.

Re^5: socio-political guidance sought
by Jenda (Abbot) on Aug 21, 2004 at 21:28 UTC

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

[reply]