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)



Subject: "isdual" returns false positives.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-25934-1390891882-115.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1915
Download (untitled) / with headers
text/plain 1.8k
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".
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-25934-1390891882-115.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-25934-1390891882-115.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-8004-1391624906-352.92527-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1637
Download (untitled) / with headers
text/plain 1.5k
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
From daoswald [...] gmail.com Wed Feb 5 21: 51:20 2014
MIME-Version: 1.0
X-Spam-Status: No, score=-2.698 tagged_above=-99.9 required=10 tests=[AWL=-0.000, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-8004-1391624906-708.92527-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-92527 [...] rt.cpan.org> <rt-4.0.18-25934-1390891882-115.92527-6-0 [...] rt.cpan.org> <rt-4.0.18-8004-1391624906-708.92527-6-0 [...] rt.cpan.org>
X-Virus-Checked: Checked
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.194.185.113 with SMTP id fb17mr3779962wjc.29.1391655071195; Wed, 05 Feb 2014 18:51:11 -0800 (PST)
Message-ID: <CAKTcQ95K-y3e2RpsSmetKsppDnq7aYaKtn=y0f_BqWgt2tjp5w [...] mail.gmail.com>
Content-Type: multipart/alternative; boundary="047d7bd6bb0e2b287404f1b3f2db"
X-Spam-Score: -2.698
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 6CA4C24053F for <cpan-bug+Scalar-List-Utils [...] hipster.bestpractical.com>; Wed, 5 Feb 2014 21:51:20 -0500 (EST)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G4G00SkCY4T for <cpan-bug+Scalar-List-Utils [...] hipster.bestpractical.com>; Wed, 5 Feb 2014 21:51:19 -0500 (EST)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id D0028240085 for <bug-Scalar-List-Utils [...] rt.cpan.org>; Wed, 5 Feb 2014 21:51:18 -0500 (EST)
Received: (qmail 25682 invoked by alias); 6 Feb 2014 02:51:18 -0000
Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com) (74.125.82.180) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Wed, 05 Feb 2014 18:51:16 -0800
Received: by mail-we0-f180.google.com with SMTP id u57so882625wes.39 for <bug-Scalar-List-Utils [...] rt.cpan.org>; Wed, 05 Feb 2014 18:51:11 -0800 (PST)
Received: by 10.227.62.137 with HTTP; Wed, 5 Feb 2014 18:50:56 -0800 (PST)
Delivered-To: cpan-bug+Scalar-List-Utils [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #92527] "isdual" returns false positives.
Return-Path: <daoswald [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=PS/+izTKaKl8CgoNTaSNVjVdaOYdDLNxAjh7VcfYPvs=; b=Nx21jDfOyTW0QorAL8jI/m9MYTakEgJsxl0xAW3e4CLU1NXAYozrdLfvrww5RQa5Wy QfHVWYiL35kUaEXj3LfMbtwXwH3Wf4sMU9W4AB5+za5/pCxTagmcJjOCSuTaqHwV/6vq b1Lq8tegX4U7I3fOqbwr53PpEyxh1thxVEKA3OO5Gj+59Gt4xqLQlV41O2l7xGd7VNfK TnK6K5GL+b7DiiCs46bT61HGOrD7SFcPBOsbnwfSmGrHq9UU3tt6QAuYK4v/JEjSzQjk TceC8r9teYw7MVKJl8g/0VZ97YAylH3OBMk+kD95759hfaaKY6pm1zdevAnaPozUbv8M JJDA==
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Scalar-List-Utils [...] hipster.bestpractical.com
X-RT-Mail-Extension: scalar-list-utils
Date: Wed, 5 Feb 2014 19:50:56 -0700
X-Spam-Level:
To: bug-Scalar-List-Utils [...] rt.cpan.org
From: David Oswald <daoswald [...] gmail.com>
RT-Message-ID: <rt-4.0.18-1140-1391655081-527.92527-0-0 [...] rt.cpan.org>
Content-Length: 0
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Content-Length: 2541
Download (untitled) / with headers
text/plain 2.4k
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
content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 3333


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.