Skip Menu |

This queue is for tickets about the Scalar-List-Utils CPAN distribution.

Report information
The Basics
Id: 92527
Status: open
Priority: 0/
Queue: Scalar-List-Utils
People
Owner: Nobody in particular
Requestors: davido [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in:
  • 1.27
  • 1.27_001
  • 1.27_002
  • 1.28
  • 1.29
  • 1.29_001
  • 1.30
  • 1.31
  • 1.32
  • 1.33
  • 1.34
  • 1.35
  • 1.36
  • 1.37
  • 1.38
Fixed in: (no value)

History Show all quoted text
  Tue Jan 28 01:51:23 2014 davido [...] cpan.org - Ticket created
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".
  Wed Feb 05 13:28:26 2014 leonerd-cpan [...] leonerd.org.uk - Correspondence added
On Tue Jan 28 01:51:23 2014, DAVIDO wrote: Show quoted text
> 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.
Indeed; I am inclined to agree. The current implementation of isdual() is answering a question of limited use. Show quoted text
> As it currently stands, "isdual" is misnamed. As implemented, it > should have some "guts" sort of name, such as "hasPVand_NVorIV".
Unfortunately it's now sufficiently old that it couldn't easily be renamed. Ofcourse what I could do is add a new, better name for it as an alias, and also create a better behaviour as a newly-named function. I'd suggest $bool = Scalar::Util::has_str_and_num( $sv ) to answer the question currently performed; namely, that it has POK and IOK|NOK, and $bool = Scalar::Util::str_and_num_differ( $sv ) to answer the more useful question of it having both POK and IOK|NOK and yet these two containing inconsistent values. It is a somewhat long and unwieldly name, but I believe that justified by the slightly odd behaviour of the function combined with the rarity it should be needed in practice. Does that sound a good plan? -- Paul Evans
  Wed Feb 05 13:28:26 2014 The RT System itself - Status changed from 'new' to 'open'
  Wed Feb 05 21:51:21 2014 daoswald [...] gmail.com - Correspondence added
Subject: Re: [rt.cpan.org #92527] "isdual" returns false positives.
Date: Wed, 5 Feb 2014 19:50:56 -0700
To: bug-Scalar-List-Utils [...] rt.cpan.org
From: David Oswald <daoswald [...] gmail.com>
Sounds reasonable. I didn't think that isdual had been around long enough to care; I don't believe it's being used in any CPAN modules, but of course we cannot know about any uses outside of CPAN. A deprecation cycle followed by upgraded semantics might be ok. Frankly, I doubt that anyone who may be using it is aware that it is hobbled. You might just look at it as a bug fix. But if you are concerned that it's being used in the wild and don't want to go through a deprecation cycle, your suggestion of providing a more appropriate alias, as well as adding a more capable function under a new name does make a lot of sense. On Wed, Feb 5, 2014 at 11:28 AM, Paul Evans via RT < bug-Scalar-List-Utils@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=92527 > > > On Tue Jan 28 01:51:23 2014, DAVIDO wrote:
> > 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.
> > Indeed; I am inclined to agree. The current implementation of isdual() is > answering a question of limited use. >
> > As it currently stands, "isdual" is misnamed. As implemented, it > > should have some "guts" sort of name, such as "hasPVand_NVorIV".
> > Unfortunately it's now sufficiently old that it couldn't easily be > renamed. Ofcourse what I could do is add a new, better name for it as an > alias, and also create a better behaviour as a newly-named function. > > I'd suggest > > $bool = Scalar::Util::has_str_and_num( $sv ) > > to answer the question currently performed; namely, that it has POK and > IOK|NOK, and > > $bool = Scalar::Util::str_and_num_differ( $sv ) > > to answer the more useful question of it having both POK and IOK|NOK and > yet these two containing inconsistent values. It is a somewhat long and > unwieldly name, but I believe that justified by the slightly odd behaviour > of the function combined with the rarity it should be needed in practice. > > Does that sound a good plan? > > -- > > Paul Evans >
-- David Oswald daoswald@gmail.com