In a message dated Sun, 12 May 2002, Miko O'Sullivan writes: > From: "David Whipp" <[EMAIL PROTECTED]> > > It it too much to ask, of the creator of a tied array, to implement > > their code in such a way that *reading* an element of that array > > does not have significant side-effects? > > Actually, I think that *is* a significant imposition. The whole point of > tied arrays ( and hashes, scalars, etc) is that they act like arrays but > internally do whatever they want.
This reminds me of my first experience writing a kernel handler for the /proc filesystem. I was just learning how it worked, and made the handler increment an internal variable and print it every time the file was read. I was surprised to see the following behavior, when I cat'd the file several times: $ cat /proc/test Counter is 0 $ cat /proc/test Counter is 3 $ cat /proc/test Counter is 9 $ cat /proc/test Counter is 13 $ cat /proc/test Counter is 16 (Note the extra newline after 9.) This is absolutely correct behavior--if you know how the standard C library implements file I/O, you can see what's going on (hint: I used %d in the format to sprintf). But it's wildly unintuitive. But this is just how things are. If the act of reading a particular data structure has side effects, especially side effects that cause the semantics of the data structure to alter, code which expects ordinary semantics, where reading is idempotent, will behave unexpectedly. Trey
