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

1. I don't know of any way to cause a hash key to be created by use of an "if" test.

Correct. There isn't. An other operator has to come into play. However, the following fools many since the operator is invisible:

if ($hash{foo}{bar}) download

See my reply to the OP. Interesting...I will have to experiment with this. 2nd hash dimension wasn't part of the question.

2. I don't know of any way to cause a hash key's value to be "non-existant".

delete $hash{foo}; delete @hash{qw( foo bar )}; 
delete local $hash{foo}; 
# Since 5.11.0 delete local @hash{qw( foo bar )}; 
# Since 5.11.0

[download]
I'm only on 5.10, so learned something new. Update: still don't see it, ie. how to leave the key but have the value of that key be anything other than undef,string(null or not) or number. To the best of my knowledge a hash key will always evaluate to at least undef. delete $hash{foo} removes key foo and its value.
When you test a hash key, you are testing the value of the key. It can be true or false. false values are: "undef","",'',0

The string "undef" isn't false. Plain old undef is, though.
Yes this was a typo, quotes were wrong to use.

The second and third literal you posted are the same value.

And you're missing some. Except for some insane situations, anything that stringifies to "" or "0" is false. The common false values are undef, the empty string, 0 and "0".
no disagreement here. 0 and "0" I believe will wind up being in practice the same thing.

4. If a hash key value "exists" then it can have any one of the 4 values above. Not true. Aside from the fact that you only listed three values, a hash value can be an scalar, not just false ones. 5. If a hash key value is "defined", then there only 3 possibilities. Not true. It can be any scalar value except undef.
I meant the false values, you are correct.
Update: Added lots as I found that every claim had serious errors.
perhaps not one of my better posts..posted code works as claimed, but explanation could have been better.

Thanks for your clarifications.

Replies are listed 'Best First'.
Re^4: Best Hash Practices?
by ikegami (Patriarch) on Oct 09, 2009 at 05:05 UTC

    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"

[reply]
[d/l]
[select]
      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]

In Section Seekers of Perl Wisdom