Scalar::Util::blessed

Hi,

>     # Hope nobody defines a sub by this name
>     sub UNIVERSAL::a_sub_not_likely_to_be_here {
ref($_[0]) }
> 
>     sub blessed ($) {
>       local($, $SIG, $SIG);
>       length(ref($_[0]))
>         ? eval { $_[0]->a_sub_not_likely_to_be_here
}
>         : undef
>     }

is there any reason to pollute UNIVERSAL here? Shouldn’t
the
following work identically?

    sub blessed ($) {
      local($, $SIG, $SIG);
      length(ref($_[0]))
        ? eval { $_[0]->can('can') && $_[0] }
        : undef
    }

-- 
*AUTOLOAD=*_;sub
_{s/(.*)::(.*)/print$2,(",$/","
")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle

On Wed, Oct 10, 2007 at 12:01:05 +0200, A. Pagaltzis wrote:

I agree FWIW, but it should return ref($_[0]), not $_[0] in
the true
case.

Nice touch remembering local(), you++

-- 
  Yuval Kogman <nothingmuchwoobling.org>
http://nothingmuch.wo
obling.org  0xEBD27418

On Oct 10, 2007, at 5:01 AM, A. Pagaltzis wrote:

> Hi,
>
>>     # Hope nobody defines a sub by this name
>>     sub UNIVERSAL::a_sub_not_likely_to_be_here {
ref($_[0]) }
>>
>>     sub blessed ($) {
>>       local($, $SIG, $SIG);
>>       length(ref($_[0]))
>>         ? eval {
$_[0]->a_sub_not_likely_to_be_here }
>>         : undef
>>     }
>
> is there any reason to pollute UNIVERSAL here?
Shouldn’t the
> following work identically?
>
>     sub blessed ($) {
>       local($, $SIG, $SIG);
>       length(ref($_[0]))
>         ? eval { $_[0]->can('can') && $_[0]
}
>         : undef
>     }

No it will not. What if the class of $_[0] has over-ridden
can ?  
However, you can call $_[0]->UNIVERSAL::can('can') to
avoid that

Graham.

* Yuval Kogman <nothingmuchwoobling.org>
[2007-10-10 12:20]:
> I agree FWIW, but it should return ref($_[0]), not
$_[0] in the
> true case.

Err, d’oh, yeah.

> Nice touch remembering local(), you++

Thanks, but I can’t claim credit; that was already there
in the
original version. 

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/&g
t;

ON WED, OCT 10, 2007 AT 12:01:05PM +0200, A. PAGALTZIS
WROTE:
} HI,
} 
} >     # HOPE NOBODY DEFINES A SUB BY THIS NAME
} >     SUB UNIVERSAL::A_SUB_NOT_LIKELY_TO_BE_HERE {
REF($_[0]) }
} > 
} >     SUB BLESSED ($) {
} >       LOCAL($, $SIG, $SIG);
} >       LENGTH(REF($_[0]))
} >         ? EVAL {
$_[0]->A_SUB_NOT_LIKELY_TO_BE_HERE }
} >         : UNDEF
} >     }
} 
} IS THERE ANY REASON TO POLLUTE UNIVERSAL HERE? SHOULDN€™T
THE
} FOLLOWING WORK IDENTICALLY?
} 
}     SUB BLESSED ($) {
}       LOCAL($, $SIG, $SIG);
}       LENGTH(REF($_[0]))
}         ? EVAL { $_[0]->CAN('CAN') && $_[0] }
}         : UNDEF
}     }

THIS IS ALSO INCORRECT IN THE FACE OF THE ""
CLASS. AT LEAST IT
WORKS AGAINST THE '0' CLASS.

I WAS ABOUT TO PROPOSE THE FOLLOWING CODE AS A TEST FOR
OBJECT-HOOD
BUT IT FAILS TO FAIL AS EXPECTED.

  MY $SELF = [];
  MY $METHOD = SUB { WARN 'OK' };

  $SELF->$METHOD; # OK

APPARENTLY HAVING CODE ON RIGHT SIDE CAUSES PERL TO NOT CARE
WHAT'S ON
THE LEFT SIDE.

  0->${SUB{}}
  UNDEF()->${SUB{}}

ETC.

DRAT.

-- 
JOSH

On 10/10/07, josh <twistsgmail.com> wrote:
> Apparently having code on right side causes perl to not
care what's on
> the left side.
>
>   0->${sub{}}
>   undef()->${sub{}}
>
> etc.
>
> Drat.

Yes, this is very weird stuff IMO. I discovered this the
other day,
and frankly think its pretty counter intuitive.

Cheers,
yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"