Evaluating opinions (was Re: "compile" vs."tokenize"(wasRe:Password Problem))

[Jay R. Ashworth]

On Thu, Jun 03, 2004 at 07:18:33PM -0400, Kenneth Brody wrote:
> "Jay R. Ashworth" wrote:
> > On Thu, Jun 03, 2004 at 04:09:06PM -0400, John Esak wrote:
> > > being worse than useless... and etc. They are not problems you encounter by
> > > mis-using the GETNEXT command and then complaining that _it_ is broken...
> > 
> > If the documentation does not say "you can't do this while changing
> > the key field of the record that you looked up, and expect it to work
> > right", then *I am not misusing it*.
> [...]
> 
> If you change the major key field of the index you are using to step
> through the file, what would you expect GETNEXT to do?  Isn't the "next"
> record the one following the current record?  If I change the key from
> SMITH to BRODY, shouldn't the "next" record be the one that follows BRODY?

That doesn't actually speak to whether the behavior is documented, but
since that behavior seems not to have any value, whereas stepping
through *what order the records were originally in* does, then yes, I
expect the designer to go for the miswart and cache the "next pointer"
when arriving at the record, and use *that* on the GETNEXT.

It doesn't break the case where you didn't change the key, and it makes
useful the otherwise useless (at least, *I* can't see any use for it)
behavior which currently occurs if you *do* change the key.

Strictly, yes, the "next" record *should* be the one that follows
BRODY... but can you suggest a situation where someone might actually
desire that behavior in a GETNEXT loop across a child file?

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

        "They had engineers in my day, too."  -- Perry Vance Nelson