Re: Sometimes undef is initialized and sometimes not when hash values are fed to grep

@LanX

One workaround would be to surround every value with quotes "$h{bla}" , to enforce a copy.

-- thank you. That's good hint. I have tried also $h{bla} // "".

@haukex

I'm pretty sure the answer is the same as in your previous thread that you referenced: map is providing lvalue context to its args, while the other two examples of string concatenation do not, hence the hash value is autovivified.

Yess.. this is the same problem. Sorry for coming again with the same...


    $ perl -wMstrict -MData::Dump -e 'my %h; map{$_} $h{X},"$h{Y}"; dd
+\%h'
    Use of uninitialized value $h{"Y"} in string at -e line 1.
    { X => undef }
[download]

Hmmmm... only one warning... It doesn't warn about X. Educative example.

I'm curious why you have so many issues with autovivification? Personally, I hardly ever do, because I use exists, or keys when looping over multiple hash keys.

In my company (dubielvitrum.com, manufacturer of mirrors) there is manufacturing system written in perl. And all data is kept in structured files, with strict data types (numbers, identifiers, quoted texts). This data is checked carefully on input and output. When undef gets somehow into hash then error is thrown. So I have to search how undef got injected into data structures. Original piece of code that made that error was like this:

        $wi{OrderUniqueId} = join " ", grep { $_ ne "" } map { unquote
+_text($_) }
                ($ty eq "need" ? "Zamów" : "Posia"), $$it{name}, $$it{
+para}{Termin}, $$it{para}{Ile}, seq_num(6);
[download]

To build OrderUniqueId I take (1) word "Zamów" or "Posia" (2) name of item (3) parameter "Termin" (4) parameter "Ile" (6) some sequence number -- take all non empty of these, join them with spaces.

 
$wi{OrderUniqueId} = join " ", grep { $_ ne "" } map { unquote_text($_
+) }
                ($ty eq "need" ? "Zamów" : "Posia"), $$it{name}, $$it{
+para}{Termin} // "", $$it{para}{Ile} // "", seq_num(6);
[download]

Normally when working with perl I hardly ever got errors from autovivification when aliased with grep or map.

Comment on Re: Sometimes undef is initialized and sometimes not when hash values are fed to grep Select or Download Code

Replies are listed 'Best First'.

Re^2: Sometimes undef is initialized and sometimes not when hash values are fed to grep
by haukex (Archbishop) on Feb 12, 2020 at 12:20 UTC

This data is checked carefully on input and output. When undef gets somehow into hash then error is thrown.

Ok, I see. Although of course there are exceptions, I find it easiest to work with hashes in one of two ways: either a fixed set of possible keys, in which case one can avoid autovivification issues by not differentiating between exists and defined, so it doesn't matter whether a key is present or not, and undef simply indicates "no value". Or, the other situation is a set of keys that is unknown to the code beforehand, in which case one generally only iterates over the hash with keys etc., and one doesn't generally access specific hash keys by name.

It sounds like you might be mixing these two - although there are sometimes valid cases where a hash has a known set of keys and one does want to differentiate between exists and defined, I've found this to be a little annoying to work with. For example, in my module IPC::Run3::Shell, there are options that can be exists but not defined, but then there is no easy way to override these options so they no longer exist in the hash.

Anyway, In the code you showed, I might have gone with exists checks to prevent autoviv, even if that makes the code more verbose.

[reply]
[d/l]
[select]


Keep It Simple, Stupid
	PerlMonks