Brent Dax wrote:
>
> I was writing up some docs (in a perldoc-like style--we can always
> change the form later, but the content is important), and started
> working on documenting references. I ended up with this bit:
I imagine (if there are no objections) that the general perldoc writing
style (booklike, informal) is probably exactly what we want, yes? We'll
just break it up into *much* smaller individual sections, so that only
one concept is being taught at a time. Probably.
> =head3 Autovivification
> @{%anagrams{$key}}.push $word;
> $undefined_var[$idx]=$scalar;
Hmm, not a clue. I could argue that one both ways. Perhaps (thinking
aloud) they only autovivify if you've explicitly called out the exact
type they store, but otherwise generate an exception? (Because it seems
like the behavior would be _very_ handy if you wanted it, and a real
pain in the $#@ when you invoked it unintentionally.)
So maybe if you previously declared them like this:
my \Array %anagrams;
my \Array $undefined_var;
you'd get autovivifying behavior (but what the heck is the syntax for
"stores a reference to an Array"? The above doesn't seem bad, but I'm
just guessing.)
but if you declared them like this:
my %anagrams;
my $undefined_var;
you wouldn't, because it would be "too ambiguous" (for the programmer,
not the compiler. :-)
Of course, this problem is closely related to the problem of determining
whether any arbitrary object autovivifies:
my MyObj $obj = undef;
$obj.foo();
.... I'd argue that if the first example autovivifies, this one should
too. (And yes, I realize we're using the term in a not-strictly-Perl5 way.)
MikeL
