Re: The Bad, the Ugly, and the Good of autovivification

[Anonymous Monk]

It's a bit unfair to blame autovivification for your typo. Even without the typo, the value of $exists is possibly wrong. And a good test suite would have tested for this - it would have run a text which would set $exists to a true value. And then fail because that didn't happen.

But the problem is deeper. The problem is using string literals as hash keys, because that more or less turns hash elements into variables - with all the drawbacks of package variables, and then some. If you want a variable, use a (preferably) lexical variable. Don't fall for the sweet lures of "oh, just stuff it into a hash" - it's worse than turning off strict. If you do need to populate a hash, put the index into a constant (with Readonly) or a variable.

Remember the old rule "never put magic numbers inside your program - use constants". But that applies to strings as well. Don't use string literals - use constants. And don't blame autovivification if you do use string literals and burn yourself.

[tlm]

The "typo" was just a convenient way of illustrating a "hash key that got messed up somehow". This can happen in less trivial ways. E.g. a bug in a regex can send you down that path. Still, to this one could reply, well, fine, bugs happen, what's new? The reason for my bringing all this up is to point out that in the presence of autovivification such mangled keys lead to two errors. One is the familiar one: the fetching of nonexistent values leaves one with variables at the receiving end that are erroneously set to undef. It's the second one is the one that blindsides newcomers: the creation of new hash keys as a side effect. Programmers, I think, are more sensitized to the former than to the latter. As I said elsewhere, the most insidious bugs are those whose possibility one is not even aware of. Moreover, in my experience, these autovivification bugs would often manifest themselves far away (in the program's logic) from where the error happened.

[Anonymous Monk]

*shrug*

I don't get your point. open could cause havoc as well if you've botched up the second argument (or third if you use three arg open). Is that the fault of open? If you match a regex against a string you've botched up, you get the wrong result. Does that mean matching has an "ugly" side? If you pass in the wrong arguments, most functions will do the wrong thing - but that's not the fault of said function. It's the fault of the caller of said functions.

Let me quote an early computer pioneer:

On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

Charles Babbage

[tlm]

Well, I'm beginning to repeat myself, so this will be my last attempt. The post from the start was a comment on how the standard sources of Perl documentation give short shrift to the issue of autovivification-related bugs, and that this is something that should be corrected (either that, or change the way Perl autovivifies to eliminate the most common of these bugs). The Perl documentation would be perfectly accurate, but much less useful, if it limited itself to describing how things work without ever mentioning pitfalls. You conveniently give the example of open: well, the Perl docs are rife with admonitions against failing to check the return value of open. There should be similar warnings about autovivification bugs. At the very least they deserve an entry in perltrap, and a pointer to this entry in perlref, and even also in perlreftut