Re: To be, or not to be, an object ?

I usually use Scalar::Util::blessed. Never failed me so far. Would your approach work with autobox?

Update: Your suggested solution has a (nearly obvious) pitfall:

sub Foo::isa { die "bla" };
my $ref = bless {}, 'Foo';

eval { $ref->isa() };
if ($@) {
    print "Not an object\n";
}
else {
    print "An object\n";
}
[download]

Also in general this construct:

eval { ... }
if ($@) { ... }
[download]

Isn't all that reliable because a DESTROY sub might clear $@ accidentally. Rather use

if (eval {...; 1}){ ... }
[download]

Instead (Ok, this is nit-picking, but you asked for reliability...).

Comment on Re: To be, or not to be, an object ? Select or Download Code

Replies are listed 'Best First'.
Re^2: To be, or not to be, an object ? by Bloodnok (Vicar) on Jul 25, 2008 at 13:32 UTC
Hi moritz , JIC you were wondering about the justification for this diversion, I'm working in an environment whereby the ad-hoc downloading and use (pun intended:-) of CPAN modules is a non-trivial exercise:-( Back OT, if the conditional were to change to ... `if ($@ =~ /can't call method without a package or object ref/) {...`, then the problem would, methinx, be circumvented unless there was a package perverse enough to `die "can't call method..."` in an overloaded `isa()`. BTW, wouldn't your latter point put at risk all that we're told regarding the use (pun unintended this time:-) of `eval` to catch errors and handle them locally - the risk of `DESTROY` f%*&^ing things up in such circumstances must be almost omnipresent... mustn't it ?? Just a thought... At last, a user level that overstates my experience ... as I'm beginning to most ably demonstrate :-))	[reply] [d/l] [select]
Re^3: To be, or not to be, an object ? by moritz (Cardinal) on Jul 27, 2008 at 20:18 UTC
Back OT, if the conditional were to change to ... `if ($@ =~ /can't call method without a package or object ref/) {...`, then the problem would, methinx, be circumvented unless there was a package perverse enough to die `"can't call method..."` in an overloaded isa(). Yes. Except that I always hated this kind of hack, because it relies on the exact phrase of the error message. Which might be subject to change, to l10n or whatever. BTW, wouldn't your latter point put at risk all that we're told regarding the use (pun unintended this time:-) of eval to catch errors and handle them locally - the risk of DESTROY f%*&^ing things up in such circumstances must be almost omnipresent... mustn't it ?? Yes, it is indeed. There was a lengthy thread on p5p about that, and how to fix it. Thankfully only very few modules actually use a eval inside a `DESTROY` block without localizing `$@` first. If you don't need a return value from the eval block, you can also do this check: `my $success = eval { # your stuff here... 1; };` [download] and then check for the truthness of `$success`.	[reply] [d/l] [select]
Re^4: To be, or not to be, an object ? by Bloodnok (Vicar) on Jul 27, 2008 at 23:14 UTC
Doohhh!! It's only just dawned on me what's happening in your suggested solution - within the context of the `eval`, the code does indeed `die`, `croak` etc. hence 1 is returned from the eval iff the included code doesn't collapse in a heap - told you I was being rather myopic:-) Thanx again for your insightful comments moritz. At last, a user level that overstates my experience :-))	[reply] [d/l] [select]