The problem is that your overload function does not take into account the differences when being called as a conventional method, and when it is called via the overloading. In the latter case, there is an extra 3rd parameter identifying the ordering of the operands for the operator.

From the overload pod:

Calling Conventions for Binary Operations

The functions specified in the use overload ... directive
 are called with three (in one particular case with four,
 see Last Resort) arguments. If the corresponding operation
 is binary, then the first two arguments are the two 
arguments of the operation. However, due to general object 
calling conventions, the first argument should always be an
 object in the package, so in the situation of 7+$a, the 
order of the arguments is interchanged. It probably does
 not matter when implementing the addition method, but 
whether the arguments are reversed is vital to the 
subtraction method. The method can query this information
 by examining the third argument, which can take three 
different values:


FALSE - the order of arguments is as in the current operation.
TRUE - the arguments are reversed.
undef - the current operation is an assignment variant (as in $a+=7),
        but the usual function is called instead.
[download]

Thanks BrowserUK - I read perldoc overload but didn't recognize that this was the problem. I guess the only decent solution is to provide the stringify() function explicitly that returns the name without the extra functions in the name() mutator method.

[Jon]

I'm a bit confused because when overload is triggered, it appears to be passing 'undef':

#!/usr/local/bin/perl
                                                                      
+          
package SomeClass;
use Data::Dumper;
                                                                      
+          

use overload '""' => \&name;
sub new {
   return bless {}, shift;
}
                                                                      
+          
sub name {
    print Dumper \@_;
    my $self = shift;
    $self->{NAME} = shift if @_;
    return $self->{NAME};
}
                                                                      
+          
package main;
my $thing = SomeClass->new;
$thing->name('TestObj');
print "Implicit: my name is $thing\n";
[download]

That gives the following output:

$VAR1 = [
          bless( {}, 'SomeClass' ),
          'TestObj'
        ];
$VAR1 = [
          bless( {
                   'NAME' => 'TestObj'
                 }, 'SomeClass' ),
          undef,
          ''
        ];
Implicit: my name is
[download]

We can clearly see 'undef' is being passed and that's what's throwing off your conditional. This is so counter-intuitive that I assume I'm missing something, though a quick scan through the docs doesn't reveal what that would be.

We can clearly see 'undef' is being passed and that's what's throwing off your conditional. This is so counter-intuitive that I assume I'm missing something, though a quick scan through the docs doesn't reveal what that would be.

The relevant part of the documentation is:

       Calling Conventions for Binary Operations

       The functions specified in the "use overload ..." direc­
       tive are called with three (in one particular case with
       four, see "Last Resort") arguments.  If the corresponding
       operation is binary, then the first two arguments are the
       two arguments of the operation.  However, due to general
       object calling conventions, the first argument should
       always be an object in the package, so in the situation of
       "7+$a", the order of the arguments is interchanged.  It
       probably does not matter when implementing the addition
       method, but whether the arguments are reversed is vital to
       the subtraction method.  The method can query this infor­
       mation by examining the third argument, which can take
       three different values:

       FALSE  the order of arguments is as in the current opera­
              tion.

       TRUE   the arguments are reversed.

       "undef"
              the current operation is an assignment variant (as
              in "$a+=7"), but the usual function is called
              instead.  This additional information can be used
              to generate some optimizations.  Compare "Calling
              Conventions for Mutators".
[download]

The first argument is the object, no surprise here. Since the stringify operation is a unary operation, the second argument is undefined. The third argument is the empty string, which is false, but defined. And this fits the description of the documentation - the arguments aren't reversed, nor is the operation an assignment variant.

Abigail

Thanks for the idea to check what's being passed into name(). I confess I really have no idea why the undef is being passed in there either though.

[Jon]

sub name {
    $_[0]{NAME} = $_[1] if defined $_[1];
    $_[0]{NAME};
}
[download]

Good on you dragonchild. I tend to not work with elements of @_ directly as I'm always afraid that the "readability police" will get me ;-) but that snippet is fairly clean and clear. Always good to make the brain re-examine its assumptions. Thanks.

[Jon]