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
>

Reply via email to