On 2/26/07, Yuval Kogman <[EMAIL PROTECTED]> wrote:
On Sun, Feb 25, 2007 at 23:22:13 -0800, Joshua ben Jore wrote:
> Ick!!!! Neither ref nor blessed have never been a booleans before and
> even this doesn't change that. Ref couldn't even used to decide if you
> had an object because the two false values '' and '0' can both be
> returned by objects:
>
> ok( ref( bless( ..., "\0" ) ), 'Detected object' ) # fails
> ok( ref( bless( ..., 0 ) ), 'Detected object' ) # fails
>
> The only boolean you'll ever have on Perl 5 is defined( blessed( ... )
> ). It's a bad pattern to rely on ref(). Or... all '' and '0' using
> classes were using UNIVERSAL::ref then... maybe... ref() could be
> considered a boolean. I'd have to be convinced.
But do you have an alternative? ;-)
I'm of the opinion that it is clear and blatantly an error to ever use
ref as a boolean. I suppose it depends on who interested I am in being
sure what I've been given is an object or not or perhaps a more
specific question.
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.
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.
Is there any language or notation for making this boundary more
explicit without just salting the code with it? I see things like C<if
( ref ) {> as fat or salt or something that has integrated itself into
the code. If it were being talked about separately then perhaps
there'd also be space for dialog about the code's opinions on proxy
objects, deferred values, isa checking, DOES checking, dunno. All that
stuff.
Josh
PS, it occurs to me that it's odd to accept an object or value. Having
an actual condition like C<if ( ref ) {> where you don't also care
about references seems unusual. Are you sure that's not a bug?
