method chaining fails where separate method calls succeed in DBIx::Simple

[Anonymous Monk]

I created a Moose object which has a method which produces a DBIx::Simple instance. When this method is called and the results placed in a scalar:

    my $s   = constructor();
    my $dbs = $s->dbs;
    my $r   = $dbs->query($Q);
    my $h = $r->hashes;

then everything works fine. But, but when you attempt to chain together the method calls:

 my $s = constructor();
 my $r = $s->dbs->query($Q);

the result is not the same - you get a dead object.

The reason this happens is that on line 165 of Simple.pm there is an attempt to reduce the reference count by double-quoting the database handle related to the statement handle:

# $self is quoted on purpose, to pass along the stringified version,
# and avoid increasing reference count.
        $st = bless {
            db    => "$self",
            sth   => $sth,
            query => $query
        }, 'DBIx::Simple::Statement';
        $statements{$self}{$st} = $st;

A fix that works for me is to simply remove the double quotes. Then all 3 test cases in the test program below work. So I guess my questions are:

1. The simple fix for me is to pass the actual database object instead of the stringified version. is there any practical case where passing the actual database object would lead to problems?
2. What is it about method chaining versus several separate method calls that is leading to premature object death?
3. Is it reasonable to expect method chaining to work the same as breaking down the method chain into a series of separate calls?
4. If there are cases where having the database object as part of the statement object poses problems, then how can we support method chaining and also avoid the problems caused by it?

personally, I don't understand why line 165 of Simple.pm looks the way it does. I asked Juerd about it and here is what he said:

> Also, is there a reason you didnt use Scalar::Util::Weaken instead o
+f
> quoting an object like that?

I'm not entirely sure what the reason was in this specific case, but i
+n
the general case I think it's safer to just have a string, than to hav
+e
something that when copied does increase the refcount, and could still
be destroyed when you didn't expect it yet. If all you need is somethi
+ng
to recognise the object when you see it, then keeping the entire objec
+t
around is just unnecessary bloat; bloat that could cause many hours of
debugging.

And that makes no sense to me:

• Increasing the refcount is no big deal. It just means the statement handle is not extinguished until the database handle is
• There is no bloat in adding the reference because it is not cloned. It's the same reference, just referred to in one more place.