<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I did not mean to reply only to John on this, so I am sent to list.<br>
<br>
In defense of case insensitivity. <br>
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.<br>
<br>
Just an option,<br>
<br>
Richard D. Williams<br>
<br>
<br>
Fairlight wrote:<br>
<blockquote type="cite" cite="mid20040720194655.D6049@iglou.com">
<pre wrap="">Is it just me, or did John Esak say:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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..."
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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->
</pre>
</blockquote>
</body>
</html>