filepro quirk

[Nancy Palmquist]

Fairlight wrote:

> The honourable and venerable Laura Brody spoke thus:
> 
>>On Thu, 28 Oct 2004 14:23:52 -0400, Roger Cornelius <rac at custom-mobility.com> wrote:
>>
>>
>>>I've been absent from this list for awhile and have a couple of filepro
>>>related questions.  The first is below.  I'll post the second
>>>separately.
>>>
>>>dreport v 4.8.10D4 on SCO OSR5.0.7
>>>
>>>I have the following code:
>>>
>>>         If:
>>>       Then: import WORD imp=(if)
>>>	   ...
>>>
>>>         If: imp(2) eq "TX"
>>>       Then: gosub TXTYPE
>>>         If: imp(2) eq "TXA"
>>>       Then: gosub TXATYPE
>>
>>	Just swap the two elements so that you test for
>>the longest string first. You would also do it this
>>way if you were writing an edit which was trying to
>>match "TXA" or "TX".
>>
>>	This partial matching is quite handy when you
>>want to select records where a field starts with
>>a value.
> 
> 
> My $0.02 worth...
> 
> If they won't implement all of extended regexp's, shouldn't they at least
> make a partial match a subset of 'co', with an ^ anchor, and let eq be
> a true equality?  It's always been my opinion that "equals" should mean
> "equals".
> 
> I could even accept the argument when the issue was brought up a few months
> back and it concerned case sensitivity, I think, citing McKenzie, MCKENZIE,
> etc.  I can see that on indexes, et al.  Okay, fine, valid point.
> 
> But cases sensitivity and giving a false positive based on differing
> lengths are two totally different things.
> 
> Jay would probably have a field day with this.  I don't care all that
> much, other than to say that I agree it is -not- what a programmer would
> ordinarily expect from a test for equality.  It's more akin to "like 'TX%'"
> in SQL.

He did not test equality - he tested for equivalence.  They do not mean 
the same thing.  I have to say that I do not find this counter intuitive 
at all.  My training is in Mathematics and this is exactly the right way 
to match equivalence.  The least significant item determines the 
accuracy of the comparison.

Since he compared a left justified 2 character literal to a left 
justified 3 character literal, the least significant literal was 2 
characters so that is all that is compared.

This same logic would apply to decimal places in numeric calculations. 
It would determine how many decimals are significant in a result.

Just because the rules applied in other languages (all developed after 
filePro had set down its logical structure) does not mean that filePro 
did it wrong.

Nancy
> 
> That may be handy, but it's a pretty strange definition of equality, IMHO.
> 
> And out of curiosity, how would you "just" switch the order in which you
> compare them, if they were not literal strings, but were actually values
> contained in other variables--and, say...more than two of them.  You start
> getting into matrix algorithms then, and that's particularly gruelling.
> 
> Maybe they just need a new operator "em" for "exact match" that accounts for
> -exact- equality, both case, full length, etc.  
> 
> mark->


-- 
Nancy Palmquist
Virtual Software Systems
PHONE: (412) 835-9417			Web site:  http://www.vss3.com