Re^3: gotchas with hash element autovivification

~~Yes, but that's not what I said. I didn't say a Seahorse hash, I said Seahorse *entry*:~~ Whoops! I certainly did!

$ cat autovivify.pl 
#!/usr/bin/perl
use strict;
use warnings;
use Data::Dump qw(dump);

my %h = (A=>0);

print "Foo" if defined $h{Apple}{Banana}{Seahorse};

$h{Apple}{Banana}{Seahorse}=undef;

print "Bar" if defined $h{Apple}{Banana}{Seahorse};

print dump(\%h);

$ perl autovivify.pl
{ A => 0, Apple => { Banana => { Seahorse => undef } } }
[download]

As you can see, if the Seahorse entry exists defined can still return false.

In my (clearly incorrect) mental model of hashes, the defined function and the perl compiler, defined would be passed the contents of the *value* slot of the Seahorse entry. So I expected that the Seahorse entry would be created so that the compiler could hand defined the undefined value. This is one of perl's irksome (to me) quirks.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Update: Repaired, per tobyink's note.

Comment on Re^3: gotchas with hash element autovivification Select or Download Code

Replies are listed 'Best First'.
Re^4: gotchas with hash element autovivification (lvalue) by tye (Sage) on Apr 03, 2012 at 14:06 UTC
Autovivification requires an lvalue "context". Just reading a value won't autovivify it. Both defined and exists are known to Perl to be read-only and so won't autovivify the last level of dereferencing. Just testing a hash also won't autovivify (the last level). So I disagree with tobyink's "this would make the `defined` keyword kinda useless" because it hints that defined is somehow preventing autovivification. That's particularly problematic because that is actually a common misconception. Just testing defined or exists has no different behavior with regard to autovivification than directly testing the hash entry does. And even when some function "would be passed the contents of the value slot of [an] entry", that isn't always enough to cause autovivification. Perl is (sometimes) smart enough to make the autovivification dependent on whether the function actually makes a modification. `my %hash; sub list { print join( ' ', sort keys %hash ), $/ } for( $hash{for} ) { # Don't do a single thing to $_ } list(); # 'for' entry autovivified unconditionally sub maybeset { for( $_[0] ) { $_ = $_[1] if 1 < @_ }; list() } maybeset( $hash{maybe} ); # no 'maybe', despite the for() in th +e sub maybeset( $hash{set}, 'hello' ); # now 'for set'` [download] - tye	[reply] [d/l]
Re^5: gotchas with hash element autovivification (lvalue) by roboticus (Chancellor) on Apr 03, 2012 at 14:36 UTC
tye: Thanks, that clears it up somewhat. Sometimes I wish perl were just a little less DWIMmy...or that it would dwIm! ;^D ...roboticus When your only tool is a hammer, all problems look like your thumb.	[reply]
Re^4: gotchas with hash element autovivification by tobyink (Canon) on Apr 03, 2012 at 13:11 UTC
I didn't say a Seahorse hash, I said Seahorse entry You said both. `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply]