note
tye
<p>
Sounds like [mod://Data::Compare] is broken. A quick peek at the source turned up exactly the type of broken code that I expected to see:
</p><c>
if(ref($requires) ne 'ARRAY') {
</c><p>
So just fix Data::Compare. The fixes would probably be quite simple. The best fix is to change such things to:
</p><c>
if( ! eval { @$requires; 1 } ) { # Can't be used as an array ref
</c><p>
It is fine to use [ref] as a Boolean test. Any other uses of [ref] I simply can't recommend.
</p><p>
Note that the above trick doesn't work for CODE references so you have to resort to one of the second-best methods. I'd use the following:
</p><c>
*isa= UNIVERSAL::isa;
#...
if( isa( $ref, "CODE" ) ) {
</c><p>
Note that this test can fail in the case of [mod://overload]ed objects that want to pretend to be CODE references but that didn't bother to <c>push @ISA, "CODE";</c> in order to declare this intention (which seems a perfectly reasonable restriction to me). [chromatic] would surely cringe and moan upon seeing such code because surely <c>$ref->isa("CODE")</c> is what should be used (except, of course, that it is likely to [die] in many cases). <c>eval { $ref->isa("CODE") }</c> might be a possible alternative but I thought it had its own drawbacks even though I can't recall what they were. My preferred method can also produce false positives if somebody intentionally lies via <c>push @ISA, "CODE";</c> which I also consider to be a perfectly reasonable feature (which can even be useful when writing unit tests, for example).
</p><p>
Looking at the code further, I see one spot that would be somewhat complex to fix because it assumes that a reference can only be of one type, which is not the case. But it would also simplify other parts of the code, because there would not have to be special code for looking under the covers of blessed references.
</p><p>
Actually, perhaps it would be best to leave the plug-in handling alone, despite the flawed assumptions present there. Replacing the flawed assumptions with proper handling when considering handlers for specific classes of objects would be quite complex and you don't need to fix plug-in support in order to fix the basic flaw in the module; thus making it work fine on [mod://DBM::Deep] results.
</p><p>
Then the module becomes quite easy to fix (and the fixes still simplify some parts). The best route would probably be to write the following tiny helpers:
</p><c>
sub isArray { eval { @{$_[0]}; 1 } }
sub isHash { eval { %{$_[0]}; 1 } }
sub isScalar { eval { ${$_[0]}; 1 } }
sub isCode { UNIVERSAL::isa( $_[0], "CODE" ) }
</c><p>
And then the less-tiny helper:
</p><c>
sub getCommonRefType
{
my( $ref1, $ref2 )= @_;
return "ARRAY" if isArray($ref1) && isArray($ref2);
return "HASH" if isHash($ref1) && isHash($ref2);
return "SCALAR" if isScalar($ref1) && isScalar($ref2);
return "";
}
</c>
<div class="pmsig"><div class="pmsig-22609"><p align="right">
- [tye]<tt> </tt>
</p></div></div>
665030
666538