So the only lesson you take away from these two threads is to continue avoiding direct contact with Juerd? I'm still wondering what your goal is with these posts. But then, I already said so in 917893.
Re^3: How should a fork of DBIx::Simple be handled?
Replies are listed 'Best First'.
So the only lesson you take away from these two threads is to continue avoiding direct contact with Juerd?
No not at all. I wasnt getting any email replies from him. I sent him
a test case via email. He ran it and it worked for him. So I revised
it and tye tried it and saw the problem and I sent him
the fixed one. And he has said nothing since then via email, so I
filed it as a RT ticket. And there
has been no movement on the RT ticket I supplied a few weeks ago. But
since he replied to me here, it seems that he is willing to work with
me in some fashion. And I will definitely keep him in the
loop. Although I prefer he stay in the loop by following me on
And his (and your) insistence on paying money for rapid feedback means
I'd rather just do everything on my own because I have urgent demands
for rapid evolution of this module and can no longer play backseat
and/or pay money.
I'm still wondering what your goal is with these posts.
Hmm, well I wanted to get a feel for what (not)? to do and how (not)? to do
it. The most likely thing to occur is that DBIx::Simple will be forked
and I will document each change as I commit on github. I wont make any
sort of CPAN release for a long time because we just need changes
locally now. Over time, the various things I do might make their way
into his code or a separate module.
But the issue that my bug
raises is actually a point of divergence. I dont think he will ever accept
that patch and change his code to quit using fiddling with reference
counts. And my test case MUST work for what we are doing locally.
Are you going to call your fork DBIx::Simple::CircularReferences or DBIx::Simple::NeverDestroys?
and tye tried it and saw the problem
What I "saw" was that you should simply stop writing code that destroys the container object if you want to keep using one of the contained objects. But you insist on making a simplistic change to the DBIx::Simple module and not making a trivial change to how you use that module, even after I made it quite clear that your proposed change breaks the lifecycle management of the module.
Unless you proposed a patch that fixed your "bug" without creating circular references, I would make the next "movement on the RT" to close it as "working as designed".