in reply to Re: The wonders of Test::More
in thread The wonders of Test::More

That's deeply confusing

Indeed. To begin with, it was a case of TL;DR, so it took me a couple of weeks to summons the energy to actually look at it ;-)
I initially just changed the condition form '!=' to '<' (which was actually a more appropriate condition anyway) and any failures were then reported normally.
This issue is actually cropping up in a new module I'm putting together, and there's one particular function that I haven't yet got quite right ... hence the occasional failures.

The diagnostics suggest that, after the $unoverload() call, both $got and $expect are still Math::MPFR objects, unaltered in any way.
Devel::Peek::Dump() calls done before and after the $unoverload() call, confirm this.

$unoverload is the string "_unoverload_num", which by the look of it (I'm guessing) disables the '0+' overloading.
There is no '0+' overloadinging in Math::MPFR - I've never bothered with '0+' because I've never hit a case where it serves a useful purpose.
AFAIK, when a Math::MPFR object is used in a numeric (unoverloaded) context, then the stringification of that Math::MPFR object is automatically used in numeric context. And that has always served just fine.
(Mind you, this new module I'm playing with might well require '0+' overloading, as I doubt that the stringification will DWIM when used in numeric context.)

I know there are aspects of overloading that I don't understand well ... and '0+' overloading could well be one of them.
I think that Math::GMPq is the only module where I've overloaded '0+', and that was done simply because strings like '11/65537' don't DWIM when used in numeric context.
For example, the condition ('11/65537' == '11/2') is TRUE .... and that doesn't DWIM well at all.

Cheers,
Rob

Replies are listed 'Best First'.
Re^3: The wonders of Test::More
by Anonymous Monk on May 22, 2022 at 14:15 UTC

    Hugo here, I was typing up a response to this last night when my computer died stone dead with a strong whiff of ozone. I'll be offline for a few days until I can get that fixed.

    I found that the issue could easily be replicated with something roughly like the below. (This is from memory, I'm in a local hotel to write this.) Please verify and report to the Test::More bug queue.

    The problem appears to be occur when a) the '!=' test fails, b) the object(s) being tested have '!=' and '""' overloading but not '0+'. I have not checked if both arguments need to be objects, nor if other comparators are affected.

    use Test::More; package Ov { use overload ( '""' => sub { 'x' }, '!=' => sub { 0 }, }; }; cmp_ok(bless({}, 'Ov'), '!=', bless({}, 'Ov'), 'failing test'); done_testing();
      I was typing up a response to this last night when my computer died stone dead with a strong whiff of ozone

      Undoubtedly the result of having subjected the machine to this insidious bug ;-)

      Please verify and report to the Test::More bug queue

      With a small typo fixed, your script demos the problem correctly - and I've tested that the addition of '0+' overloading to that demo avoids the issue.
      ( There was a '}' that needed to be replaced with a ')'. )

      I have now reported the bug.

      Cheers,
      Rob

        I have now reported the bug.

        Thanks, I've commented there. Happily the ozone was readily diagnosed as a PSU failure (does Antarctica know?), so I only had 40 hours discomputered.