|Subject:||"isdual" returns false positives.|
I've read the discussion earlier in the RT for Scalar::Util pertaining to the proposed "isdual" function. I believe the consensus in that thread was that detecting a dualvar should be positive if information will be lost when printing the variable (for example), and that, in specific, if the IV or NV is not equivalent to the string contained in the PV. In other words, we do not have a "dualvar" if $x == 10 and $x eq '10'. Consider the following code: use Scalar::Utils qw( isdual ); my $x = 10; print "$x\n"; print isdual($x), "\n"; __OUTPUT__ 10 1 So despite that the stringified scalar and its integer component agree with each other, it is being reported as a dualvar. It's always been my impression that what we consider to be a dualvar is a variable where the IV or NV and the PV disagree with each other. If the return value of isdual is now the new definition of what constitutes a dualvar, the definition has become so inclusive as to be practically worthless. Do we really want to call any scalar that has a numeric and string component dualvars, even if those components are in complete agreement, and resulted only from an internal stringification or numerification? I doubt it. I see that this behavior is documented, but it is still incorrect behavior. If someone just wanted to know if there's an active IV and PV component (even if they agree with each other), the B module offers such introspection. Scalar::Util shouldn't be so concerned with exposing an implementation detail. What it should be concerned with is whether the user needs to be concerned that the IV and PV disagree with each other. That elevates its usefulness from simply leaking implementation details, to divulging information that has relevancy to the actual use of a variable. As it currently stands, "isdual" is misnamed. As implemented, it should have some "guts" sort of name, such as "hasPVand_NVorIV".