in reply to Re^4: Hooks like Storable for Dumper?
in thread Hooks like Storable for Dumper?

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'];

[download]

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'];

[download]

What do you think? I'm very open to ideas about this. And willing to be convinced that another approach is better.

---
$world=~s/war/peace/g

Replies are listed 'Best First'.
Re^6: Hooks like Storable for Dumper?
by xdg (Monsignor) on Jan 03, 2006 at 18:49 UTC

    I like it. Among other things, it might allow one serializer to fall back to another. E.g. if YAML doesn't find a freezer defined for it, it could theoretically fall back to DDS.

    The only other way that I think might make sense is for a package to have the hash, e.g.

    our %FREEZE_THAW_FOR;
%FREEZE_THAW_FOR{ "Data::Dump::Streamer" } = [ 'foo', '->bar' ];
%FREEZE_THAW_FOR{ "Data::Dumper" } = [ 'foo', 'bar' ];
%FREEZE_THAW_FOR{ "YAML" } = [ 'foo', 'bar' ];

    [download]

    It all amounts to the same thing really -- mapping between packages and serializers in some package variable space. I think I moderately prefer your approach, though a part of me is leery of the globals either way. Seems like there ought to be a better way -- maybe a third party module that packages can register with and serializers can query, but then you wind up in dependency hell.

    I think the KISS and YAGNI principles would suggest doing it your way.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
[d/l]

      I think I moderately prefer your approach, though a part of me is leery of the globals either way.

      I agree. In general I'm leery of the globals too.* I would like to know why you moderately prefer my approach as your reversal hadn't occured to me at all and I'm wondering what tilts you in the direction of my proposal.

      * Globals have the advantage that you can use local on them to affect dynamic changes. For instance to resolve one of your issues from another part of this thread you could create a wrapper sub that localizes $Data::Dumper::Freeze and $Data::Dumper::Thaw before calling into Data::Dumper. Using a pure object approach (like DDS) means that you have to have seperate serialization objects, which in turn makes it difficult to "override" a default set of properties for a limited duration. Anyway, I apologise for the digression, I just thought I should use this chance to explain why I think that Data::Dumper's dynamic var approach actually makes sense. (Even though at first glance it doesnt :-)

      ---
      $world=~s/war/peace/g

[reply]
        I'm wondering what tilts you in the direction of my proposal.

        Off the cuff:

        • Not having to worry about strict or use vars or our and backwards compatibility. Your approach just explicitly forces fully qualified names.

        • External fully-qualified names makes it clear where the mappings are used. I think that will help those maintaining the code follow the action.

        • Doesn't pollute the package namespace with a special variable the package doesn't even use itself.

        (Regarding globals and local: Yes, indeed. Have you seen Object::LocalVars?)

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom