On 16 October 2010 03:59, Ricardo Signes <perl...@rjbs.manxome.org> wrote: > > Tonight I uploaded Test::Deep 0.108. The changes made are very small, and > should not affect anyone other than some edge cases in which it should be > faster. > > Many of the open bugs relate to unfortunately named exports like "blessed" and > "isa," and to behavior that should probably change but would break existing > scripts. I'd like to improve the way in which exports are organized and > generated. > > "use Test::Deep" would be equivalent to "use Test::Deep -v0" which would be > the > current set of exports. The new set of catch-all behavior, mostly the same > but > with "blessed" and "isa" renamed would be "-v1". Other exports could be > grouped in other ways to get things like "use Test::More -objects, > -containers" > or something along those lines. Using Sub::Exporter would make this very > easy, > and would allow a lot of other tricks like getting all the exports with a > prefix on the names. ("td_bag" instead of "bag" for example.) I'm not sure > whether there will be general chafing at the new prereq, though. > > Another common complaint is the lack of clear docs about what is and isn't > exported. I'd like to get the export situation cleared up before documenting > everything, so this is more or less tabled. > > Finally, there's a bug that cmp_deeply($have, $want) should compare both parts > of a dualvar. I think this is a mistake, and am likely to reject it with > alternate ways to write that test. I am open to argument now, but I think > it's > pretty likely that I'll follow through with this plan.
One principle of Test::Deep is that the comparator (the second argument) controls the comparison. So, if $want is a string and $have is a dualvar then string comparison is what you should get. If $want is a dualvar then it becomes a bit tricky because then it's not clear which is the correct comparison (string is what happens today because non-refs are compared using Shallow.pm which uses eq for defined non-refs). Sticking with the principle, $want being a dualvar should result in dualvar comparison. However at this late stage, that would almost certainly break existing code so seems like a bad idea. Right now anyone needing dualvar comparison can use all(num(23), str("foo")). Adding a convenience function for that (or even just documenting it) seems reasonable, F > -- > rjbs >