Re: Re: How can I find the calling object?

[John M. Dlugosz]

Note that there are some funky issues that mean you _cant_ reliable replace the overload::StrVal calls with plain old reference stringification.

Do go on...

[demerphq]

To coin a phrase, a snippet is worth a thousand words...

package Foo;
use overload qw("" stringify fallback 1 + zero);

sub stringify {
  "overload.pm just ruined your day!"
}

sub zero { 0 }

package main;
my $foo1=bless {},'Foo';
my $foo2=bless {},'Foo';

sub same { "'$_[0]' is ".($_[0] eq $_[1] ? "the same as" : "different 
+to" )." '$_[1]'\n" };


print same(0+$foo1,0+$foo2);
print same($foo1,$foo2);
print same("$foo1","$foo2");
print same(overload::StrVal($foo1),overload::StrVal($foo2));

__END__
'0' is the same as '0'
'overload.pm just ruined your day!' is the same as 'overload.pm just r
+uined your day!'
'overload.pm just ruined your day!' is the same as 'overload.pm just r
+uined your day!'
'Foo=HASH(0x1acef84)' is different to 'Foo=HASH(0x1acf038)'

:-)

AFAIK, the _only_ non-xs way to reliably determine the underlying variable type and class of an overloaded object is to parse the results of overload::StrVal. Even then you get nowhere with reblessed qr// objects. (Which still act as regexes at the same time.)

Frankly the fact that perl completely lacks any reliable native perl way of doing type introspection is IMO one of its few serious failings. (And no, at least some of the problems do not go away with Scalar::Utils and List::Utils.)

--- demerphq
my friends call me, usually because I'm late....

[John M. Dlugosz]

OK, you're saying that if the object overloads stringify, then you won't get the normal string for the hash or array.

But what does parsing the StrVal left of the = sign do that ref() doesn't?

[demerphq]

OK, you're saying that if the object overloads stringify, then you won't get the normal string for the hash or array.

Right. Also if it overloads numericification. (Which is worse since there isnt a overload::numval)

But what does parsing the StrVal left of the = sign do that ref() doesn't?

Im not sure where the "left" part comes from. I did a regex to check if an '=' was in the name only to determine that the first parameter passed to the callers sub was indeed a blessed reference. This is a good first step, but it isnt an exhaustive check as it has no way to determine that the following are different

  foo($obj);
  $obj->foo();

If caller had a flag to say that the sub was invioked via a method then this would be a much better way to do this.

Anyway, coming back to parsing.. The result of overload::StrVal() gives three things: Base Type*, memory location/unique identifier, Class type.

Ref gives you the first if the reference isnt blessed and the class name if it is. That isnt particularly useful (in my experience) as you more often than not want to check type to see how the object should be dereferenced.

Also Base Type has a star next to it because it isnt really base type. For instance a reference to a scalar value can return no less than three completely different things: Ref, Scalar and Glob. While apparently weird it is useful behaviour though. :-)

    print join("\t",ref(\[]),ref(\"foo"),ref(\*glob),ref(\do{my $x=*fo
+o}));
    # REF    SCALAR    GLOB    GLOB

Cheers,

--- demerphq
my friends call me, usually because I'm late....