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

[John Esak]

> > not that way. He would rather be silent if he does not know a topic then
> > contribute something that might be in error.
>
> Yes, he often leaves my questions unanswered.  *This* one isn't hard to
> prove, at all.

I'm sorry Jay, but many (in fact, sadly most) of your questions) do not
merit any response from anyone... Why, because you place them in this
caustic, sarcastic, mostly disrespectful and quite "worng" tone...


--excerpt from the very last message you just left on the list-----

  > *** A filePro Error Has Occurred ***
  >
  > Array Index Out of Range: dim prffac(7) -- Index: -35
  >
  > Output Processing
  > Line Number: 22
  >
  > ai=prffac[np]*lia(11)
  > ^
  > Process contains a syntax error at position indicated.
  > -----------------------------------------------

  Clearly, the syntax error is at '[np]', not at the beginning of the line.

  Could I take a moment to explain the concept of "worse than useless" in
  the context of error messages that give too much detail, and it's worng?

  Jay R. Ashworth

--end-of-excerpt------------

I use this example because it is so sarcastic and so "over the top" and so
completely "worng". Though it is a splendid example of 90% of your
contributions here.
Just because you *say*  "Clearly" the syntax error isn't precisely at the
carat pointer..." and you feel it should point directly at the array,
doesn't make it so. I, in fact, totally disagree. The ^ is pointing to the
beginning of the segment of code that contains an error... anyone can pass
there eye along the segment to find the error... ESPECIALLY because it is so
exactly described directly above as an array error. There is NO need to
point directly at the array itself...  Maybe that would be nice if someone
had trouble in telling where the array was in the segment... but it's
obvious, no?  Now, even if you had let it go at your pontificating "Clearly
it should be THIS way and no other..." states... EVEN that would, I suppose
be okay... but you further go on to say the totally nasty and completely
unnecessary next line... about it being "worse than useless".  Jay, a post
like this (as most of yours regarding filePro are) is what I consider "worse
than useless"... it is more than that, though, it is offensive as well.  And
you expect to get "answers" to posts like these from Ken or anyone else?
Don't hold your breath. Better yet, use your breath to shout at compiler
designers who right that the error is on or near line 276. It would be just
as meaningless there though. The syntax checker is meant to provide good
indications of what might be wrong... not waste time trying to cross-connect
myriads of combinations of possible positions at which to place the pointer
for you. A good description of the problem and pointing to the precise line
where the problem is... well that's pretty good enough I think. Yes, there
are times I've seen the carat at the wrong place, but it is almost never on
the wrong line... and that's more than I can say for my Borland 5.0.

>
> Case in point: if you walk an file on an index *in processing* (a loop,
> say, on a child file), and execute code that a) modifies the key
> file, and b)
> uses getnext, that code will fail, because the filepro dclerk routines
> that handle the lookups do not cache in advance what the next and
> previous records *ought to be when you get to the current one* (in the
> remote file).
>
> The code will miss child records, because the pointer will jump against
> the backdrop of the universe of appropriate records in the child file
> *after you rewrite the key field* -- some records will be visited multiple
> times; some may be skipped altogether.
>

How UTTERLY ridiculous! Almost not worth responding to this... but oh
well...

1) You should not be using getnext if the code is modifying the key...
sheesh, do something wrong and then complain that it doesn't work write...
:-)  That's pretty good Jay... but I've seen you do this quite a bit in the
past also, so my point is made again. The error is on your side.

2) If a file were to be walked through with getnext (for whatever insane
reason a good programmer might want to do this... although I can't think of
any...) the description you gave of how it works is EXACTLY how I would
expect it to work and furthermore would WANT it to work. The getnext process
should point to where it would naturally point if the key were not being
modified.  If the simple procedure of moving out of the getnext loop and
restarting at the correct point isn't observed, than NO other functionality
should be expected.  It is flatly obvious to me why this was never fixed
since you reported it in the great detail you say. It was not and is not
broken as you say it so (CLEARLY obviously) is. It was you who mentioned
design decisions... I'm very happy it was designed as it is... it is totally
predictable, reliable and sorry to say "clearly" working as it should. I'd
be happy to send up some code that shows how to work with a lookup file
which is changed during a loop... although it would NOT use the GETNEXT
construct, which is simply the incorrect tool for the need.


> The point is that it is not necessary to *be* Ken to evaluate how well
> Ken's products, and the support systems that surround them, serve their
> intended target audience: professional applications programmers like me.

No, of course not, and I did not come even close to saying that... However,
one does need to be nice, well mannered and courteous about suggestions,
which _you_ never are. Try it sometime you might get those answers you say
people aren't giving you. I'm sorry I questioned you about your background
and the programs you have written. I can see it has really hit a sore point.
As for your saying you don't think filePro is a killer app... and um, you've
used it for 15 years... well, um... CLEARLY you wouldn't know a killer app
if you saw one. :-)

I will not be answering any more on this thread you have turned it into some
kind of a flaming thing... not gonna byte. :-)

John

Visit The FP Room www.tinyurl.com/yuag7 24/7