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

Regarding the equivelent to Storable, just use the Freeze()/Thaw() method (as per Data::Dumper) to register the method. Im reluctant to hard code the method names as I dont think it scales well. 

use DDS;

sub Popsicle::Freeze {
    my ($self)=@_;
    $_[0]=bless \do{my $x=join "-",@$self},ref $self;
}

sub Popsicle::Thaw {
    my ($self)=@_;
    $_[0]=bless [ map {split /-/,$_ } $$self ],ref $self;
}

my $ig=bless ["A".."C"],"Popsicle";
my %h=(One=>1,Two=>2,Three=>$ig);

# "fix" statement thaw...
Dump->Names('first')
   ->FreezeClass('Popsicle'=>'Freeze')
   ->ThawClass('Popsicle'=>'Thaw')
   ->Data( \%h )->Out;
print "\n";

# inline thaw....
Dump->Names('second')
   ->FreezeClass('Popsicle'=>'Freeze')
   ->ThawClass('Popsicle'=>'->Thaw')
   ->Data( \%h )->Out;
print "\n";


# clear the hooks for Popsicle
Dump->Names('third')
   ->FreezeClass('Popsicle'=>'')
   ->ThawClass('Popsicle'=>'')
   ->Data( \%h )->Out;
print "\n";

# Using FreezeThaw to make it a bit easier...
Dump->Names('fourth')
    ->FreezeThaw('Popsicle'=>'Freeze','->Thaw')
    ->Data( \%h )->Out;
print "\n";

# Using generic hooks and not class specific ones
Dump->Names('fifth')
    ->Freeze('Freeze')
    ->Thaw('->Thaw')
    ->Data( \%h )->Out;
print "\n";

__END__
$first = {
           One   => 1,
           Three => bless( \do { my $v = 'A-B-C' }, 'Popsicle' ),
           Two   => 2
         };
$first->{Three}->Thaw();

$second = {
            One   => 1,
            Three => bless( \do { my $v = 'A-B-C' }, 'Popsicle' )->Tha
+w(),
            Two   => 2
          };

$third = {
           One   => 1,
           Three => bless( [
                      'A',
                      'B',
                      'C'
                    ], 'Popsicle' ),
           Two   => 2
         };

$fourth = {
            One   => 1,
            Three => bless( \do { my $v = 'A-B-C' }, 'Popsicle' )->Tha
+w(),
            Two   => 2
          };

$fifth = {
           One   => 1,
           Three => bless( \do { my $v = 'A-B-C' }, 'Popsicle' )->Thaw
+(),
           Two   => 2
         };

[download]
---
$world=~s/war/peace/g

Replies are listed 'Best First'.
Re^4: Hooks like Storable for Dumper?
by xdg (Monsignor) on Jan 03, 2006 at 18:02 UTC
    Im reluctant to hard code the method names as I dont think it scales well.

    I'd like to better understand your reasoning. One advantage of the Storable approach is that it's defines an interface that modules can implement in order to manage their interoperability with Storable. E.g. Object::InsideOut and Class::Std::Storable.

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

      Warning this node contains a u-turn of opinion that would impress even a well salted politician...

      I think I finally clicked to why Storable uses the approach it does and why despite the other points raised I think it actually makes more sense. In two words:

      Respect Inheritance!

      The point is that if you define a Storable_freeze() method all Storable has to do is say $obj->can('Storable_freeze') (in a heavy XS accent of course ;-) and it knows if the object needs special handling. With my approach I have to do a hash lookup on the classname, so subclasses won't inherit their freeze/thaw handlers.

      Which brings me to the point of starting to think that my approach is actually subpar and that it makes a lot more sense to copy Storable's approach. Which leaves me in the uncomfortable situation of wanting to support both. Sigh.

      I think that given a classname register would break inheritance I'm going to have to provide DDS_freeze and DDS_thaw support. I guess supporting both approaches has its merits as they are to a certain extent complementary. IE, you could use the existing mechansim to override the DDS_ method hooks if you wanted to.

      Anyway, live and learn I guess.

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

[reply]

      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

[reply]
[d/l]
[select]

        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]

In Section Seekers of Perl Wisdom