There’s no autoviv involved here. Autovivication is the implicit allocation of references of the proper type when undefined lvalues are dereferenced. There is no dereferencing here. | [reply] |
| [reply] |
Ah ... sorry I was wrongly thinking perl's auto extending of arrays is the same thing as autoviv.
You’re right in that both behaviors derive from a common principle that Perl takes care of memory allocation for you. This is very different from C, Java, or even Python, all of which blow up if you try to overindex an array, and certainly never auto‐allocate new ones to multiple levels as occurs with autoviv.
It’s just that the way the jargon has developed in Perl culture, the word autoviv always involves implicit allocation of references (into previously undefined lvalues that are getting dereferenced), not merely extending an existing string, array, or hash with non-reference data.
Non‐autoviv examples:
my $s = "a";
$s .= "abcdefghijklmop";
my @a = (0 .. 4);
$a[55] = "frog";
my %h = (red => 1, blue => 2, yellow => 3);
$h{green} = 6.02e23;
Autoviv examples:
my $hr = undef;
$hr->{radish} = "crunch"; # yes autoviv
$hr->{banana} = "squish"; # no autoviv
my @a = ("a" .. "z");
$a[0][1] = "new level"; # yes autoviv
$a[0][9] = "new element"; # no autoviv
my %h = ( );
$h{little}{dog} = "puppy" ; # yes autoviv
$h{little}{cat} = "kitten"; # no autoviv
$h{male}{cattle} = "bull"; # yes autoviv
$h{male}{cat} = "tom"; # no autoviv
See the difference?
| [reply]
[d/l]
[select] |
