browse keys (@bk)

[Richard D. Williams]

I did not mean to reply only to John on this, so I am sent to list.

In defense of case insensitivity.
I feel the users would find it confusing. Do we really need upper case 
and lower keys to launch a process at a browse lookup?  Besides, I have 
written browse lookup that act like a select box on the internet.  The 
operator starts to type and the browse reacts with every addition 
letter. Upper and lower case would not help, in fact the lookups used in 
a browse are not case sensitive in *ix or win versions of filepro.

Just an option,

Richard D. Williams


Fairlight wrote:

>Is it just me, or did John Esak say:
>  
>
>>By this logic, Mark, you would also disagree with Mr. Bourne (and a hug host
>>of other language designers)... Unfortunately, or fortunately, the use of
>>    
>>
>
>Actually, in most Bourne-esque shells, [ is actually an external to
>/usr/bin/[ which is a symlink to /usr/bin/test.  That's been my experience.
>
>  
>
>>any operator (like eq for example...) is just a matter of explanation and
>>convention... in other words, *this* is how it works here... and this is how
>>it works somewhere else... For Jay, or anyone, to say filePro is doing it
>>*wrong* is (I'm sorry to say) is just ridiculous... It is just another
>>attempt to start and argument where there is no reason for one. To use your
>>comment above, the way "eq" works in the shell would be *wrong* also, but I
>>don't see you or Jay writing to AT&T, Berkeley or Linus...
>>
>>$  num1=2
>>$  num2=3
>>$ [ num2 -eq num1 ] && echo "All eq's must work the way Jay says..."
>>    
>>
>
>But that's not (from my interpretation) what he's saying.  "2" and "3" (in
>filePro parlance, quoted, so we're sure they're actually numbers, not
>fields), are always going to differ, of course.
>
>AFAIK, Jay was talking about -strings-.  'test' = 'TeSt' will test negative
>in /usr/bin/test.  I just checked.  And the operator is different there as
>well--it's an "=", not "eq", which is reserved for numerical comparisons in
>Bourne/test.  I don't quibble about what it's -called-.  But your saying
>that I would say 'eq' is "wrong" in fP is not entirely accurate, based on
>your assumptions, precisely because Bourne's "eq" operator is numeric-only,
>not string.  But fP makes no such distinction, and both are handled with the
>same operator.  However, even reduced to numerical constructs (say,
>converted to hex, decimal, whatever), 'test' will not equal 'TEST' with the
>case difference.  And by default, even in Bourne, that tests as it
>should--in the negative.  fP tests in the positive by default, requiring
>you to use COMPARE().  The only instance in which they should actually test
>literally equivalently is after a soundex conversion, I should think.
>
>-All- I'm saying is that the default of most places (including Bourne on
>stock SCO 5.0.6, I just tried) is a case -sensitive- comparison on
>-strings-.
>
>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.
>
>  
>
>>was adopted as the best design at the time. My issue with Jay's statements
>>that it is wrong... well, I can't say it any plainer, can I. He just wants
>>an argument where really is nothing to argue about. It is not the eq that is
>>"wrong", it is his statements about it.
>>    
>>
>
>Well, it's certainly unexpected if you come from other languages--even as
>archaic as BASIC.  Since COMPARE() is fully usable in conditional
>statements (I wasn't aware it was), I also see no actual argument.  I would
>simply expect, as a newcomer to fP if I were one, that case would be
>accounted for.  This isn't the case, but one can easily work around it--at
>least since 4.5.
>
>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->
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.celestial.com/pipermail/filepro-list/attachments/20040720/f436004f/attachment-0001.html