Subject | Re: [IBO] EOF BOF craziness |
---|---|
Author | Paul Vinkenoog |
Post date | 2003-09-10T10:40:20Z |
Hi Paul,
testing for Eof/Bof, TDataset and TIB_Dataset behave the same.
on Eof. IBO gets away from referring to a record that isn't there,
TDataset gets away from processing the last record more than once.
I think IBO is safer here, because if you make the mistake of exiting
too late, you'll either get an error or (in the case of the AsSomeType
properties) the field values are nil.
In TDataset, the last record would be processed more than once, which
may or may not be harmful depending on what you are doing. (But if you
are summing values for instance, such an error may go unnoticed for a
long time.)
Anyway, I wouldn't call this "getting away with it". Suppose you have
this loop (with Strl a TStringList):
for i := 0 to Strl.Count - 1 do
begin
<do something with Strl.Strings[ i ]>
end;
Do you feel you "get away with it" because you stop just short of
attempting to access Strl.Strings[ Strl.Count ] ?
job for you.
access the first one, you _are_ past the end. Same as with the
TStringList loop.
outermost border of the dataset", i.e. just beyond the last record,
or as "at the last record", just as you consider the end of a book to
be on the last page, or maybe even the back cover, but not past the
back cover.
Bof is even worse (to me), because I do consider the first record to
be the beginning of the set. Probably I'm conditioned by all those
loops where you start at the beginning (valid unless equal to end) but
you bail out just before the end (which is an invalid position).
But then, TDataset.Eof is also a misnomer, because you can't use it to
test if you are on the last record. Like you said, it's now a flag to
indicate that your _attempt_ to go past the last record failed. (And
not even that, because if you call Last in your code, you aren't asking
to go past the last record; yet TDataset.Eof becomes true.)
OK, no use trying to convince each other any further! It all depends
on how you look at things. But I liked this thread because it's good
to see that what's perfectly natural and logical for one person may
not be that for someone else - without either of them being "wrong".
And it made me define _why_ I like TIB_Dataset.Eof the way it is. And
I (re)learned something about TDataset in the process...
Greetings!
Paul Vinkenoog
--> End-of-mail. Don't try to read this line, it's invalid! <--
>> To me, the IBO way is much, much cleaner and more consistent.That's right. If you loop through the dataset using Next/Prior and
>
> I still dont agree :-)
>
> Firstly - 'While not eof do next' would not be broken.
testing for Eof/Bof, TDataset and TIB_Dataset behave the same.
> In fact IBO only gets away with this working because the loop exitsBoth TDataset and IBO get away with it because you exit the loop
> after the last next and does not attemp to process the record last
> pointed to.
on Eof. IBO gets away from referring to a record that isn't there,
TDataset gets away from processing the last record more than once.
I think IBO is safer here, because if you make the mistake of exiting
too late, you'll either get an error or (in the case of the AsSomeType
properties) the field values are nil.
In TDataset, the last record would be processed more than once, which
may or may not be harmful depending on what you are doing. (But if you
are summing values for instance, such an error may go unnoticed for a
long time.)
Anyway, I wouldn't call this "getting away with it". Suppose you have
this loop (with Strl a TStringList):
for i := 0 to Strl.Count - 1 do
begin
<do something with Strl.Strings[ i ]>
end;
Do you feel you "get away with it" because you stop just short of
attempting to access Strl.Strings[ Strl.Count ] ?
> Nextly - I dont see EOF as a state, and dont see why it should be aFair enough. If that's what you want, TDataset.Eof does the perfect
> state. To me EOF is a flag that says 'your last attempt at next
> failed because you are at the end of the dataset'.
job for you.
> Also the current 'state', meaning pointing to an invalid record pastNo, but that's consistent. If there are zero records and you try to do
> the end of the dataset, does not distinguish between an empty
> dataset and a full one gone off the end.
access the first one, you _are_ past the end. Same as with the
TStringList loop.
> Perhaps I should propose that the current functions are renamed BBFI agree that the name Eof is ambiguous. You can interpret it as "the
> (Before Beginning of File) and PEF (Past End of File) and modify the
> BOF and EOF source using the code in the NavBar ;-)
outermost border of the dataset", i.e. just beyond the last record,
or as "at the last record", just as you consider the end of a book to
be on the last page, or maybe even the back cover, but not past the
back cover.
Bof is even worse (to me), because I do consider the first record to
be the beginning of the set. Probably I'm conditioned by all those
loops where you start at the beginning (valid unless equal to end) but
you bail out just before the end (which is an invalid position).
But then, TDataset.Eof is also a misnomer, because you can't use it to
test if you are on the last record. Like you said, it's now a flag to
indicate that your _attempt_ to go past the last record failed. (And
not even that, because if you call Last in your code, you aren't asking
to go past the last record; yet TDataset.Eof becomes true.)
OK, no use trying to convince each other any further! It all depends
on how you look at things. But I liked this thread because it's good
to see that what's perfectly natural and logical for one person may
not be that for someone else - without either of them being "wrong".
And it made me define _why_ I like TIB_Dataset.Eof the way it is. And
I (re)learned something about TDataset in the process...
Greetings!
Paul Vinkenoog
--> End-of-mail. Don't try to read this line, it's invalid! <--