Bug #42903 for Test-Weaken: immediate sub-reference not reported

Since this is an actual bug and the other are features, I'm pushing this to the head of my queue.

I've found the problem, coded the fix, and tested it, but I have yet to update the documentation. The fix changes the count of unfreed objects, and their order. Since this is a serious change, the new user's release will be a new major release, 2.000000. I think it is a good idea to pair major changes to the internals with a major change in the interface, so I'm also including an improved user interface. The next release will be a developer's release, with a first draft of the revised documentation. I hope to produce this shortly

"Jeffrey Kegler via RT" <bug-Test-Weaken@rt.cpan.org> writes: Show quoted text
Looks orright. You could include code snippets in among the func descriptions. I find it easier to follow a sample of an option usage etc than just words. For the "tracing memory leaks" bit you might cross reference Devel::FindRef, I've found it reasonable for tracking down why something didn't go away. It tends to be verbose and technical, but often there's a variable name or whatnot among the output that gives you a clue. Show quoted text
I expect object methods is clearer than $weaken[3] etc. The distinction between "unfreed weak" and "unfreed strong" is gone is it? I found that pretty subtle, and was going to suggest describing the motivation -- now unnecessary if it's gone :). Show quoted text
In practice that means somewhere on a continuum from "alas the concept was unworkable" to "I had a better idea" to "I'm going to break your code on a whim"! I always wish people would say which they mean :-)

I'll put code snippets and Devel::FindRef on my TODO list. Show quoted text
At first the strong/weak distinction seemed very unsubtle. Weak references require very careful handling because even implicit copying strengthens them. 1.000000 did not attempt to preserve weakness when it returned references, so I reported weak references separately because that was the only way you could know the difference. This version preserves weakness on output and can be less "in your face" about the distinction. This allows someone who does not care about the distinction to ignore it, and someone who does care to dive in face first if they like. Show quoted text
This may be open source, but you've gotta allow me to keep some things to myself. :-)

My apologies for the slow progress. I needed to catch up on bookkeeping, and rewriting the documentation into presentable draft form has taken some time. For me, adding snippets to the documentation is a major project, because I create tests for all my snippets. (Apparently many module writers who do not do this, and how they keep their snippets bug-free I cannot imagine.) I expect to have another developer's release out soon. If all goes well, the developer's release after that will be a release candidate for 2.000000.

You have a good point, but I'm going to postpone dealing with this until after 2.000000. Right now I am using Test::Differences on the Data::Dumper outputs, so that in case of error I get the differences in a nice tabular form. I want to run a few experiments to see how Test::More::is_deeply() behaves in the face of screwups. If the switchover is a lose from the point of view of perspicuous output in the event of failed tests, I'll probably decide to take my chances with changes in the output format of Data::Dumper. On Wed Feb 04 17:58:28 2009, user42@zip.com.au wrote: Show quoted text

I just uploaded 2.000000. Unless a problem shows up with cpantesters, I will close this bug in a couple of days.

Fixed in 2,000000, which cpantesters is giving a clean bill of health.