On 2/26/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
I'm of the opinion that it is clear and blatantly an error to ever use ref as a boolean.
One liners and minor snippets where you control the input data would be an exception IMO.
The correct boolean is defined( blessed( obj ) ) because this returns a true value for all objects regardless of goofy class name and a false value for everything not an object. This is purely because blessed() avoided ref()'s problem and used undef as its false value and not ''. It is impossible to bless into undef and this makes blessed() a better test.
I agree, blessed has the right behaviour, but only because '',"\0" and 0 are legal class names. reftype() however has no excuse for returning undef as all the possible legal values are determined by core and will never evaluate to false. But alas its a long time too late to change.
Although... I also think there may be a difference between code that wants the "common" truth and other code that wants the "real" truth. Dumping and serialization code probably wants to avoid being lied to. User code might be willing to accept lies and in fact, might want them. I think the real answer is that there is an oddly shaped boundary between lies being preferable or truth being preferable and that each piece of code may have a different idea of how to distinguish that line.
Exaclty. A dumper like DDS never wants to be lied to, and hence avoides using $obj->can, $obj->isa, ref() or anything that allows the object to lie about itself. Whereas most code should probably let objects lie to it. There is no black or white about this. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
