in reply to Re: The Bad, the Ugly, and the Good of autovivification
in thread The Bad, the Ugly, and the Good of autovivification

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.

the lowliest monk

Replies are listed 'Best First'.
Re^3: The Bad, the Ugly, and the Good of autovivification
by Anonymous Monk on Apr 08, 2005 at 14:51 UTC
    *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

[reply]

      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

      the lowliest monk

[reply]
[d/l]
[select]
        Patches welcome.
[reply]

In Section Meditations