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 | [reply]
[d/l]
[select] |
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();
| [reply]
[d/l]
[select] |
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
| [reply] |
