This queue is for tickets about the Type-Tie CPAN distribution.

Report information
The Basics
Id:
127576
Status:
resolved
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
peter [...] morch.com
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
(no value)



Subject: Doesn't work with Clone::clone
Date: Mon, 5 Nov 2018 12:36:28 +0100
To: bug-Type-Tie@rt.cpan.org
From: Peter Valdemar Mørch <peter@morch.com>
Clone::clone-ing a ttie-d variable causes an error when using it. I assume because of the Inside-out object implementation.

Example:

#!/usr/bin/perl -w
use strict;
use Types::Standard qw(-types);
use Type::Tie;
use Clone qw(clone);
my %hash;
ttie %hash, Bool;
$hash{a} = 1;
my $clone = clone(\%hash);
$clone->{a} = 1;

The last line dies with:
Can't use an undefined value as a subroutine reference at /usr/share/perl5/Type/Tie.pm line 118.

Guesswork at analysis:

Type Type::Tie implementation makes use of Hash::Util::FieldHash for inside-out-classes. And then it makes sense for clone not to work. And indeed line 118 includes
    $check->($val)
where $check is defined a few lines above as:
    my $check  = $CHECK{$self};
and $CHECK is a fieldhash.

So $self is cloned to a new object/ref, but new entries aren't put in %TYPE, %COERCE and %CHECK.

(It seems the Tie::* classes work fine with cloning and perldoc Clone shows that it should also work for tied variables. So I don't think it is clone per se.)

It works if I just call
    ttie %$clone, Bool;
Before operating on $clone. But...

In reality, I'm using it with Moo like so:

    {
        package MyTied;
        use Moo;
        use Types::Standard qw(-types);
        use Type::Tie;
        has field => (
            is => 'ro',
            default => sub {
                return ttie my %hash, Bool;
            }
        );
    }

    my $obj = MyTied->new();
    $obj->field->{foo} = 1;
    my $objclone = clone($obj);
    $objclone->field->{foo} = 1;

And so it would sorta break encapsulation if users of MyTied need to know to do something special for MyTied objects.

Any suggestions on how to proceed, other than not clone-ing? Not being able to clone otherwise pure Moo objects is nasty for us.

One workaround is to use Storable::dclone instead of Clone::clone and setup the hooks correctly, but it seems like a lot of work, and still breaks for Clone::clone (and I don't necessarily control what my users are going to use).

    #!/usr/bin/perl -w
    use strict;
    use Types::Standard qw(-types);
    use Type::Tie;
    use Storable qw(dclone thaw freeze);

    {
        package MyTied2;
        use Moo;
        use Types::Standard qw(-types);
        use Type::Tie;
        use Storable;
        has field => (
            is      => 'ro',
            default => sub {
                return ttie my %hash, Bool;
            }
        );

        sub STORABLE_freeze {
            my $self = shift;
            return Storable::freeze({ %$self });
        }

        sub STORABLE_thaw {
            my ($self, $cloning, $serialized) = @_;
            my $selfRawHash = Storable::thaw($serialized);
            %$self = %$selfRawHash;
            ttie %{ $self->field }, Bool;
        }
    }

    my $obj = MyTied2->new();
    $obj->field->{foo} = 1;
    my $objclone = dclone($obj);
    $objclone->field->{foo} = 1;

I suggest that unless something can be done (easily) to let clone work, then at least document this issue, so we know beforehand.

What do you think?

Peter
--
Peter Valdemar Mørch
http://www.morch.com
Generally speaking, I'd suggest replacing things like: my $objclone = clone($obj); With this: my $objclone = $obj->clone; Allowing the object to decide exactly how the cloning is performed. This would not only allow you to re-tie the cloned hash, but more generally allow objects more fine-grained control over how they're cloned. For example, if you clone an Employee object which contains a reference to a Company object that the employee works at, you might not want the cloned employee to point to a cloned company, but instead to point to the original company, even if all the other data in the Employee object, you want to be deeply cloned. I don't really want to change the inside-out objects used for Type::Tie, but I'd happily accept a patch to make it behave better with Storable's dclone.
Subject: Re: [rt.cpan.org #127576] Doesn't work with Clone::clone
Date: Thu, 8 Nov 2018 13:50:32 +0100
To: bug-Type-Tie@rt.cpan.org
From: Peter Valdemar Mørch <peter@morch.com>
I've created https://github.com/tobyink/p5-type-tie/pull/1 as a suggestion to get it working with Storable::dclone. What do you think?

Peter

On Wed, Nov 7, 2018 at 8:21 PM Toby Inkster via RT <bug-Type-Tie@rt.cpan.org> wrote:
Show quoted text
<URL: https://rt.cpan.org/Ticket/Display.html?id=127576 >

Generally speaking, I'd suggest replacing things like:

   my $objclone = clone($obj);

With this:

   my $objclone = $obj->clone;

Allowing the object to decide exactly how the cloning is performed. This would not only allow you to re-tie the cloned hash, but more generally allow objects more fine-grained control over how they're cloned.

For example, if you clone an Employee object which contains a reference to a Company object that the employee works at, you might not want the cloned employee to point to a cloned company, but instead to point to the original company, even if all the other data in the Employee object, you want to be deeply cloned.

I don't really want to change the inside-out objects used for Type::Tie, but I'd happily accept a patch to make it behave better with Storable's dclone.


--
Peter Valdemar Mørch
http://www.morch.com


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.