browse keys (@bk)

[John Esak]

>
> If someone was talking about integer comparisons, I didn't even -catch-
> that.  I'm talking purely about strings.  Now since Ken already clarified
> the ability to use COMPARE() directly in a condition line, I see it as a
> non-issue for anyone using 4.5 and up.

Whether talking about integers _or_ strings, the eq (and the =) can be used
to evaluate the contents of @bk precisely... if that is what you wanted to
do. By the way the eq and the = on an "if" line do _exactly_ the same thing
and that as far as I know _is_ the definitive answer...  So, anyway, you
could actually do something like:

        if: asc(@bk) eq asc("A") or asc(@bk) eq asc("a")
      then: whatever...

and this would work just fine. The adoption of a case-insensitive stance for
eq (=) on an "if" line was a _seriously_ good idea. I doubt very many people
using filePro 'lo these many years would differ. You say you would like it
(and even expect it, viz other languages) to be the other way around and
that filePro flies in the face of convention. Well, filePro was creating
conventions back when it started doing this stuff... not following them. And
I submit that if you had to worry about case-sensitivity for every lookup
you do and every test for data in most filePro queries... you would fast
want case insensitivity to be the default and not otherwise. The _vast_
majority of people out there type in "smi" at an index key prompt in IUA and
they would be _very_ upset if they weren't brought to the first "SMITH"
record should one exist. It is all a matter of how one uses such tests for
equality, where and when and by whom... end-users, programmers?  The one
would whole-heartedly want it one way, while, as you suggest, the other
would want the opposite. I'm sure glad it is the way it is, and I am both an
end-user and programmer. I have gotten two or three pieces of email on this
thread privately (I don't know why...) affirming that case-insensitivity in
most filePro applications is far more desirable than not... and the design
is the only thing they would ever want to see. These notes were very similar
to Mike's note.

Since as you point out the test for equality in filePro can be _both_ string
based and/or number-based, it is a rather complex issue to issue a "This is
the only way it should be and all other ways including the one which now
exists are wrong." Any operator can be assigned any methodology. FilePro
chose one that has satisfied 99.9% of the users for the entire span of its
existence. That's pretty good.  Okay, if you disagree with the 99%, plug in
_any_ number you want above 50% instead... and it still was the "right"
decision. I'm pretty sure the real number of satisfied users is far closer
to the 99% than the 50% mark, Mark. :-)  So, disregarding _any_ other
concerns revolving about other languages and conventions... most of which
didn't even exist when filePro started its life... and the idea of the
choice being *wrong* is simply not viable. I doubt you could find many who
would want the eq operator in filePro to be changed to case-sensitive... nor
the index-key test, nor the @bk test, nor anywhere else in the program where
it currently ignores case. I'm pretty damn sure about this... but, I like
you, do not see it as any kind of a hot issue, problem or point of heat.  As
always the only problem I have is and was with Jay's characterization of
filePro's design choice as being "*wrong*". It is just his way, though,
maybe we should all just learn to accept that is how he thinks.

John




>
> I don't see it as a big deal, and I've -no- wish to get between you two on
> this.  I'm simply saying it behaves the opposite of the default of most
> environments and languages--including the Bourne you brought up, if you
> apply it to strings, which is what I though the initial argument was.
> Consider:
>
> #!/bin/sh
>
> if ([ 'test' = 'TeSt' ])
> then
>      echo "Equal."
> fi
> exit
>
> That -will- test false.  They are not equal.
>
> Like I said, it's not a substantial issue if it can be worked around.
> But if "eq" is taken to be a -universal- operand for "equality" of two
> terms, it should be extended towards strings a literally as it is to
> numerals.  They're either identical or they're not.  I'm citing it as a
> concept, not as anything inherently wrong with fP.  I just believe -any-
> language should treat them literally without implicit case insensitivity.
> If perl disregarded case, I'd take issue with it there as well, believe
> me.
>
> There's something inherently problematic in my eyes with data being
> manipulated without express intent.  And essentially, a default operator
> -probably- should not manipulate the data internally...which is what it
> does when it disregards case.  You should have to take special pains to
> achieve data manipulation, via use of a separate operator.  Too many
> problems come from doing things automatically and people not
> being aware of
> the fact until it's too late.  That goes for just about anything complex,
> from computers, to cell phones, to anything.
>
> Of course, if it's -documented- as such (and I believe it was, as far back
> as I started in 4.1), then there's zero cause for serious debate.  Then
> it's a purely academic discussion of design principles and decisions, and
> that's largely subjective, within some reasonable generally accepted
> boundaries of convention.  I won't say fP is "wrong", I'll just say it
> defies convention.
>
> Actually, since we're talking about operators, -is- there any difference
> between using "eq" and "=" on a conditional line in fP?  I always read the
> manual in the 4.1 days as saying you -always- use "eq" in If lines and "="
> for assignments.  I've seen people use "=" on If lines though,
> and I wonder
> if there's a functional difference, or if it performs the same test.  I
> wouldn't mind a definitive answer after all these years.  :)
>
> mark->
> --
> Bring the web-enabling power of OneGate to -your- filePro
> applications today!
>
> Try the live filePro-based, OneGate-enabled demo at the following URL:
>                http://www2.onnik.com/~fairlite/flfssindex.html
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list