Memo magic is really distressing filepro user

[Fairlight]

When asked his whereabouts on Fri, Aug 04, 2006 at 03:07:11PM -0400,
GCC Consulting took the fifth, drank it, and then slurred:
> I have found that ANY data entry, to the current record/file, done at @key
> will not hold unless a write is executed just before the END.  

I'm just so paranoid about implicit behaviours that don't that I do
explicit write/close everywhere I can.  It may or may not be redundant, but
I at least know that I'm covered within my own code.

Ran into a problem fairly recently with someone having issues with EXPORT,
actually.  They had issues with data "dropout" where it wasn't all showing
up in the file, with most of the end just vanishing for no apparent reason.
(It became apparent to -me- that the fd was never getting flushed.)

It was a case of having no CLOSE in place; fixing the problem involved
inserting one CLOSE statement.  I don't even know if it's intentionally
meant to be this way or if it's a bug, but the reality did not mesh with
their expectations of auto-closing, as it became.  And if it's intentional,
then it's a 180 spin from many other places where it's expected and "known"
that it will auto-close.

It honestly seems safer for people to just make sure one always calls
it explicitly.  I'm like that with other languages, as well--it's not a
specific criticism of filePro.  You don't technically need curly braces
in most variable uses of rvalues in perl, either--but I always use them
because it's a uniform coding style that means I'm dressed for any
occasion.  For that matter, I don't even trust perl to auto-flush its fd's
before an implicit close of an fd on program exit--and it's documented that
it's trustable.  I just don't leave it to chance.  

Some feel it clutters code (both in fP and perl, and even in other
languages) to have things there that aren't theoretically supposed to be
necessary.  I feel it helps clarity and avoids unwanted and unintentional
bugs when you standardise on the long form of doing something with the
least amount of ambiguity possible.

mark->