in reply to Re^3: Best Hash Practices?
in thread Best Hash Practices?

To the best of my knowledge a hash key will always evaluate to at least undef.

You keep using key when you're talking about the value. Either way, I never said otherwise.

0 and "0" I believe will wind up being in practice the same thing.

They are different although usually interchangeable. And then there's "0.0". It's true while equal to zero. That's why it's important to list "0"

Replies are listed 'Best First'.
Re^5: Best Hash Practices?
by Marshall (Canon) on Oct 09, 2009 at 05:25 UTC
    I think there is a better example than 0.0, 0E0. The DBI can return this string "0E0" as a "true", success value, meaning the operation worked, but there are zero results! This is logical "true", but numeric "0".

    Your point about 0.0 is well taken.
    Update:
    And yes I should have said a hash key's value instead of just referring to the return value of the hash key or just the hash key.

    But it seems that we have tripped over something in a different direction. Folks using the DBI should be aware of this 0E0 stuff. This was/is a very clever idea.

[reply]

      I think there is a better example than 0.0, 0E0.

      I don't see why. Everything you said about "0E0" applies to "0.0".

      Folks using the DBI should be aware of this 0E0 stuff.

      Totally irrelevant. "0E0" is not the exception, "0" is. All strings are true except for "0". You hadn't mentioned "0". It's rather important because I often see people think "The var can either be a string or undef, so a simple truth test will differentiate the two."

[reply]
        When I said, Your point about 0.0 is well taken. That meant that you are correct about 0.0. Quite correct, an omission on my part.

        The reason why I mentioned the 0E0 case is: If I write code that can return a float like 0.001 or 0.0 (or a string that represents a float), usually the logical test is gonna involve more that just: if ($var), the test will have some >= or <= operators that will force the $var comparison into a numeric context and the "if" test is upon that numeric comparison. Often a range of values to decide that the number is "close enough" to be considered zero for this application's purposes. However, I could imagine some application where the test is a regex.

        0E0 is a bit different in that this value is returned when an integer is expected. I have no idea of what say 0.5 of a DBI result would be! So the reason for the mention is that this is a common value from the DBI and therefore there more chance for a coding mistake. if ($num_results) just says that the operation succeed, to find out how many results, if ($num_results >0) would be more appropriate. Probably both tests are needed to decide that "operation worked" and "returned no results".

        I didn't think that 0E0 was totally irrelevant. When I said: But it seems that we have tripped over something in a different direction. Folks using the DBI should be aware of this 0E0 stuff. I was trying to re-enforce your point with a common situation in DBI code that may trip up some folks who would otherwise nonchalantly navigate the floating point comparison pitfalls. I don't intentionally use T/F comparisons of (000.000) float values and figured that situation is much less common than this strange "integer" return from the DBI.

        Thanks for your addition of 0.0. It was correct and helpful.

[reply]
[d/l]

In Section Seekers of Perl Wisdom