FAQ
The following script fails with overload complaining it can't find any
"eq" method.

#!perl
use strict;
use warnings;
use File::Temp ();
my $fh = new File::Temp();
print "file is $fh\n";
print 1, "$fh" eq "foo", "\n";
print 2, $fh eq "foo", "\n";
__END__

That's because File::Temp only overloads the stringification.
The backportable fix is to add a method to File::Temp to implement
"cmp" (and the other ones by generation.) The attached patch does
that.

However, does this mean that overload should generate cmp from stringification ?

Search Discussions

  • Rick Delaney at Sep 25, 2006 at 2:02 pm

    On Mon, Sep 25, 2006 at 12:04:09PM +0200, Rafael Garcia-Suarez wrote:

    However, does this mean that overload should generate cmp from
    stringification ?
    It will with C<fallback => 1>. I'm a bit surprised that cmp generates
    eq without specifying fallback.

    Index: lib/File/Temp.pm
    ===================================================================
    --- lib/File/Temp.pm (r?vision 8468)
    +++ lib/File/Temp.pm (copie de travail)
    @@ -139,7 +139,7 @@
    use Carp;
    use File::Spec 0.8;
    use File::Path qw/ rmtree /;
    -use Fcntl 1.03;
    +use Fcntl 1.03_01;
    use Errno;
    require VMS::Stdio if $^O eq 'VMS';

    @@ -156,7 +156,7 @@
    ### For the OO interface
    use base qw/ IO::Handle IO::Seekable /;
    use overload '""' => "STRINGIFY";
    -
    +use overload 'cmp' => \&filename_cmp;
    I think a better patch would just be

    -use overload '""' => "STRINGIFY";
    +use overload '""' => "STRINGIFY", fallback => 1;

    --
    Rick Delaney
    rick@bort.ca
  • Rafael Garcia-Suarez at Sep 25, 2006 at 3:03 pm
    Rick Delaney wrote:
    It will with C<fallback => 1>. I'm a bit surprised that cmp generates
    eq without specifying fallback.
    Ah, yes, I keep forgetting that. Yours is better.
    I think a better patch would just be

    -use overload '""' => "STRINGIFY";
    +use overload '""' => "STRINGIFY", fallback => 1;
  • John Peacock at Sep 25, 2006 at 3:10 pm

    Rick Delaney wrote:
    I'm a bit surprised that cmp generates eq without specifying fallback.
    I don't a conceptual problem with that; 'cmp' is the same operation as
    'eq', 'lt', and 'gt' (all at once). Similarly, '<=>' is '==', '<', and
    '>'.

    However, it would be wrong for 'stringify' to be used to do some
    comparative operation without asking (i.e. without fallback). As a
    thought experiment, imagine an overloaded number class where the
    stringify would spell out the number (I18N'd of course), 'cmp' would
    throw an error, and '<=>' would operate on the numeric value. The
    "value" produced by stringify is in no way comparable here.

    John

    --
    John Peacock
    Director of Information Research and Technology
    Rowman & Littlefield Publishing Group
    4501 Forbes Boulevard
    Suite H
    Lanham, MD 20706
    301-459-3366 x.5010
    fax 301-429-5748
  • Rick Delaney at Sep 25, 2006 at 5:57 pm

    On Mon, Sep 25, 2006 at 11:10:41AM -0400, John Peacock wrote:
    Rick Delaney wrote:
    I'm a bit surprised that cmp generates eq without specifying fallback.
    I don't a conceptual problem with that; 'cmp' is the same operation as
    'eq', 'lt', and 'gt' (all at once). Similarly, '<=>' is '==', '<', and
    '>'.
    This is so if you want your operators to have similar meanings to the
    standard ones. But there is no reason why one might not want to overload
    <=> to mean something completely different, maybe a bizarre form of
    assignment operator since you can't overload '='.
    However, it would be wrong for 'stringify' to be used to do some
    comparative operation without asking (i.e. without fallback). As a
    thought experiment, imagine an overloaded number class where the
    stringify would spell out the number (I18N'd of course), 'cmp' would
    throw an error, and '<=>' would operate on the numeric value. The
    "value" produced by stringify is in no way comparable here.
    That may be true for lt and gt, although I think one could argue that
    this would just provide a stringy comparison alternative, which, while
    probably not very useful, would still be logical. Regardless, if two
    objects are equal then they will probably stringify to the same thing
    and so an automatic fallback for 'eq' would be as reasonable as the
    automatic fallback to 'lt' from 'cmp'.

    I am not advocating changing anything, just pointing out some
    inconsistencies. And I was only a *bit* surprised because I've come to
    expect inconsistent and unclear (poorly documented) behaviour from
    overload, especially wrt fallback.

    --
    Rick Delaney
    rick@bort.ca
  • Tim Jenness at Sep 25, 2006 at 6:02 pm

    On Mon, 25 Sep 2006, Rick Delaney wrote:
    On Mon, Sep 25, 2006 at 11:10:41AM -0400, John Peacock wrote:
    Rick Delaney wrote:
    I'm a bit surprised that cmp generates eq without specifying fallback.
    I don't a conceptual problem with that; 'cmp' is the same operation as
    'eq', 'lt', and 'gt' (all at once). Similarly, '<=>' is '==', '<', and
    '>'.
    This is so if you want your operators to have similar meanings to the
    standard ones. But there is no reason why one might not want to overload
    <=> to mean something completely different, maybe a bizarre form of
    assignment operator since you can't overload '='.
    <=> could be used to compare file descriptors...
    cmp will be used to compare filenames

    I'm happy to support cmp (either explicitly or through fallback).

    [this is where I admit that I uploaded a new version of File::Temp to CPAN
    a month ago so it needs to be integrated into blead. Sorry I didn't notify
    as I'm suffering from "new baby in the household" syndrome starting
    from the day of the upload...]

    --
    Tim Jenness
    JAC software
    http://www.jach.hawaii.edu/~timj

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedSep 25, '06 at 10:04a
activeSep 25, '06 at 6:02p
posts6
users5
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase