browse keys (@bk)

[Fairlight]

On Tue, Jul 20, 2004 at 04:56:34PM -0500, Mike Schwartz-PC Support & Services, the prominent pundit,
witicized:
> 
> 	However, this is NOT one of those times.  For most of the
> programming I've done, I *prefer* that equals and some of the other
> functions are *not* case sensitive.  It gets really tedious to have to check
> all the upper and lower case combinations for most data entry work.  It is
> equally tedious to have to apply an allup or other edit type to 99% of the
> data fields where I need to do compares.
> 
>  	It seems much more logical to me that filePro has the tools to make
> the compares case sensitive where they are needed, such as in writing user
> defined password routines.
> 
> 	So, as far as being "stuck" with something that you are implying was
> a bad decision 40 years ago, I would have to reply that I hope filePro would
> be designed just that same way if it were being redesigned from scratch
> today.

I have to disagree a little bit here.  In most languages (at least ones
I've used), case sensitivity is the default.

In C, which fP is written in, there's a difference between str[n]cmp() and
str[n]casecmp().  The strings.h stuff wasn't even standardised until later,
but basically the case-insensitive stuff came later in many
implementations, AFAIK.

Now if they wrote their own before the strings.h functions existed (quite
probable, as early as they started...'78 and strings.h wasn't considered
standardised until after '89), I suppose it might be understandable.  But
if it was based on the normal routines, or if it was later shifted to rely
on them, then I'd have to say they went out of their way to make it harder
to do case-sensitive comparisons.

I have to agree with the -concept- of absolute equality, at the basis of
the argument.  There's a difference between "like" and "equals", basically.
I think the 'eq' operator is simply misnamed.  I'm not saying it shouldn't
have been included, I'm saying they could have done things like:

eq gt lt co
ceq cgt clt cco

So you'd have a case-sensitive -and- case-insensitive version of the
operators and could reasonably pick which best suited your needs.  To me,
that seems perfectly reasonable.

Reasonable, but not enough to get into a heated argument over it.  I'd just
have given the developers a (simple) choice, if I'd been the one making the
call.

I'm looking at some docs:

4.5  COMPARE            Compares two values, with case sensitivity.

      Syntax:

           xx = COMPARE(expr1,expr2)

Am I to assume that you cannot simply say:

If: not compare(aa,ab)  'failure case
Then: 'do something

If you can't, then yes it's possible to compare sensitively, but you
have to use extra lines of processing to do it, assigning a value first,
then checking it, when technically it could be handled with a few extra
built-in operators.

I didn't think you could use a function on an If line in fP in this
fashion.  If you can, please tell me, because that would be Good News[tm].

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