Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Converting to boolean

by dvergin (Monsignor)
on Jun 17, 2004 at 15:53 UTC ( [id://367662] : note . print w/replies, xml ) Need Help??

in reply to Converting to boolean

My first reaction was: Why would one want do do that? Any value will act as a boolean if used in a boolean context.

But I note that this question has been posed and answered by experienced monks who give every indication of taking this matter quite seriously.

So clearly I'm missing something. I've never been aware of a need for this. Could someone offer a few cases where converting to such a "boolean" value is better than simply using the variable as-is in a boolean context.

"Perl is a mess and that's good because the
problem space is also a mess.
" - Larry Wall

Replies are listed 'Best First'.
Re^2: Converting to boolean
by hv (Prior) on Jun 17, 2004 at 16:38 UTC

    For my own code, sometimes it is to ensure I have a number somewhere that a number is required, eg when calling a function that treats undef differently (".. or if bool is undef, starts a game of nethack"), or badly ("use of uninitialised value"), or for storing in a NOT NULL database field. Another reason is where I need to use a different criterion for truthfulness:

    sub has_file { my $self = shift; my $filename = $self->filename; (defined($filename) && length($filename)) ? 1 : 0; }
    .. which would otherwise do the wrong thing for a filename such as "0".

    Primarily, though, it is for clarity: to make it clear in the code (and to allow me to make it clear in the docs) that this routine returns either 0 or 1 and nothing else. I think the concept of a boolean value is very useful, and have always considered it a shame that perl didn't have such a thing as a first class data type.

    The main benefit is to prevent leakage, both actual and conceptual. By 'actual', I mean returning (say) an object (that is of course TRUE in a boolean context) that means the reference count on the object is bumped, and the object may no longer be released when it could otherwise have been because someone is still holding on to the (conceptual) boolean that tells them whether they actually had the object.

    Similarly if such a quasi-boolean is used in some polymorphic context, it may do entirely the wrong thing: there are many examples of methods that allow a parameter to be any of (0 or 1 or a coderef), and various other cases where a particular type of object is allowed.

    The conceptual leakage is about clarity of thinking: if I am not sure that I have a true boolean value, I need always to consider whether it will do the right thing when I'm passing it around or using it in various ways. When I know that I definitely have either 0 or 1, my mind is freed to consider it in a much more simplistic fashion, and I can throw it around confident that it won't blow up in my face.


      .. which would otherwise do the wrong thing for a filename such as "0".
      Umm, perhaps I'm being too picky, but I think that was a flawed example.
      defined($filename) && length($filename)
      would evaluate correctly, regardless of the actual filename.

      Now, if you tried just $filename as the return value, that would be problematic...

      Quantum Mechanics: The dreams stuff is made of

Re^2: Converting to boolean
by dragonchild (Archbishop) on Jun 17, 2004 at 17:46 UTC
    To further elaborate on hv's excellent response, I often want to know for a fact that a value is explicitly TRUE or explicitly FALSE. Some situations:
    • Talking with another program through an interface
    • Passing values through an API, like HTML::Template
    • Dealing with people who are cute and like to use the zero-but-true value "0E0"
    • Making it explicit to the maintainer (who is usually me, 6 months down the road) exactly what this is meant for
    • Doing validation checks so that I can be certain something is useful only in a boolean context.

    It's a minor point, but it's those details that I find separate the beginner from the expert.

    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested