I'm glad you challenged me on that. To be clear: I'm not convinced im right in my opinion. Basically my concern is that using such an approach means that you end up with a proliferation of freeze/thaw mechanisms. IE, if somebody wants their class to work with Storable they have one set of method names, if they want their class to work with DDS they would need another set. And if the concept was extended you'd need the same for Data::Dumper and for YAML.
But maybe this is actually not such a big deal. There arent that many production worthy serialization tools out there, so may the proliferation is managable from the start.
Alternatively i wonder if maybe DDS should just define a hash so that modules can provide system wide defaults. IE, Class::InsideOut might include a line like:
$Data::Dump::Streamer::FreezeThaw{__PACKAGE__}=['foo','->bar'];
If YAML and Data::Dumper used the same approach then you might get code like:
$Data::Dump::Streamer::FreezeThaw{__PACKAGE__}=['foo','->bar']; $Data::Dumper::FreezeThaw{__PACKAGE__}=['foo','bar']; $YAML::FreezeThaw{__PACKAGE__}=['foo','bar'];
What do you think? I'm very open to ideas about this. And willing to be convinced that another approach is better.
In reply to Re^5: Hooks like Storable for Dumper?
by demerphq
in thread Hooks like Storable for Dumper?
by xdg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |