 | |
#1
 
| |||
| |||
|
Case Sensitivity -
03-25-2011
, 04:21 PM
#2
| |||
| |||
|
#3
| |||
| |||
|
|
Hi Can anybody give me one advantage of case sensitivity? |
*real* advantages.
--
Kevin Powick
#4
| |||
| |||
|
|
Hi Can anybody give me one advantage of case sensitivity? Given that the designers of US-ASCII deliberately made case insensitivity simple by lining up the characters so that one only has to ignore the lead bit, it does seem to be one of the stranger ideas introduced to the Pick model long after its release. Peter McMurray Well we don't _like_ it, but sometimes we have to deal with it to handle |
a) filenames in aix/unix/linux stored in an attribute or item id of
pick file
b) you are implementing an encryption or hashing or compression scheme,
as a proof-of-concept, in basic.
c) Your application accepts one-keystroke commands, and there are dozens
of valid commands. Such as 'move to row A-Z or to column a-z'
e) you're detecting or converting certain escape code strings, perhaps
terminal or printer data that you were mandated to clean up _after_ it was
formatted.
f) you're bulk-cleaning mass amounts of badly-formatted prose or
envelope
address blocks, and some of your conversion rules are case sensitive.
#5
| |||
| |||
|
|
"Excalibur21" wrote> Hi Can anybody give me one advantage of case sensitivity? *Given that the designers of US-ASCII deliberately made case insensitivity simple by lining up the characters so that one only has to ignore the lead bit, it does seem to be one of the stranger ideas introduced to the Pick model long after its release. Peter McMurray Well we don't _like_ it, but sometimes we have to deal with it to handle special requirements; *for example * * *a) *filenames in aix/unix/linux *stored in an attribute oritem id of pick file * * *b) you are implementing an encryption or hashing or compression scheme, *as a proof-of-concept, in basic. * * c) Your application accepts one-keystroke commands, and there aredozens *of valid commands. *Such as 'move to row A-Z or to column a-z' * * e) you're detecting or converting certain escape code strings, perhaps terminal or printer data that you were mandated to clean up _after_ it was formatted. * * f) you're bulk-cleaning mass amounts of badly-formatted prose or envelope *address blocks, and some of your conversion rules are case sensitive. |
Thanks for that. I should have been more specific as I was thinking
of Item-Ids. Field data should always be case sensitive where
appropriate. I get annoyed by programs that change the capitilisation
of my name from McMurray to Mcmurray. Actually I would prefer to see
the c aligned with the top of the M not the line but I can live
without that.
As for editors I got well caught by Cache ED which did not find
misspelt variables such as FOO and Foo. However their excellent help
personnel guided me to the proper editing environment which does find
them. Old habits die hard, 34 years of diving for ED is a hard one to
break :-)
Now if I could just work out the e acute for cache. In mucking around
with the keyboard I have discovered that <ctrl>` is an instant program
exit in XP so I have had to write this twice..
Peter McMurray
I do like the "more work more money" option from x
#6
| |||
| |||
|
|
it does seem to be one of the stranger ideas introduced to the Pick model long after its release. |
My recollection is the opposite: R83 was case sensitive, it was not
until AP that case insensitivity became an option; I think the default
setting of AP and D3 is "casing on"- I always explicitly turn it off
in the user or logon macro. Same goes for the original BASIC verb-
case sensitive, AP/D3 flavor COMPILE - case insensitive. The wrinkle
introduced in AP/D3 was case insensitivity of item-ids, in order to
remain backwards compatible you have to specifically make files case
sensitive, e.g. "create-file (s"
DOS is case insensitive, Unix not so much.
/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006
#7
| |||
| |||
|
|
On Mar 25, 3:21 pm, Excalibur21 <pgmcmur... (AT) gmail (DOT) com> wrote: it does seem to be one of the stranger ideas introduced to the Pick model long after its release. Hi Peter, My recollection is the opposite: R83 was case sensitive, it was not until AP that case insensitivity became an option; I think the default setting of AP and D3 is "casing on"- I always explicitly turn it off in the user or logon macro. Same goes for the original BASIC verb- case sensitive, AP/D3 flavor COMPILE - case insensitive. The wrinkle introduced in AP/D3 was case insensitivity of item-ids, in order to remain backwards compatible you have to specifically make files case sensitive, e.g. "create-file (s" DOS is case insensitive, Unix not so much. /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 |
Well we both seem to have a very different recollection. I never ran
into case sensitivity until Open Architecture or later and I started
on Reality 2.4d then R83 etc at one stage I had worked or was working
on some 11 variants. I believe that it only came in with the Unix
implementations. It was about the time of AP that someone dreamed up
the idea that all Item IDs should be numeric. Not a good idea and I
am quite certain that it was dreamed up to get around the major fault
of case sensitive IDs. One does not want FOO and Foo to turn up as
two separate stock items.
The D3 default is definitely case-insensitive ie FOO = Foo = foo etc
Peter McMurray
As an aside I mentioned the <ctrl>` in XP, to my utter amazement when
I just tried it again it immediately flashed up the page that had
vanished yesterday.
#8
| |||
| |||
|
#9
| |||
| |||
|
|
Perhaps as a tie breaker... R83 was case sensitive at TCL and in BASIC statements. For data, dict items also perceived data in a case sensitive manner. (Which is why we needed to do do the trick where MCT was both a conversion and a correlative in order to get nice output with case-insensitive filtering.) Some MV systems/flavors are still like that. When a user enters data, IIRC R83 was even case sensitive at INPUT, which is why we needed to do this: INPUT YN IF YN = "Y" OR YN = "y" THEN ... Some systems are still finicky about that and for cross-platform mobility I still occasionally code like this: IF OCONV(YN,"MCU") = "Y" THEN ... Because some systems have UPCASE() and others UCASE(), I avoid the functions and go with the OCONV(). AP (maybe OA) introduced complete case insensitivity across the board, too much for some people, but for me and others it was perfect. IIRC, GA R91 had this too, and other MV platforms were getting it at about the same time (1991). Even today I still get hung up with freakin stupid casing issues in some platforms (U2 in particular) but in D3 I simply don't need to think about it, and that's why it's important. As Scott mentioned, D3 has controls that allow case-sensitivity to be implemented for keys, data, and in BASIC - to allow D3 to look as primitive as all of the other MV variants for sites that require it.  With regard to "It was about the time of AP that someone dreamed up the idea that all Item IDs should be numeric." I've never heard of such a thing. Perhaps you dreamed that up?  T |
find the U2 implementations irritating in this regard.
To confirm, OA did have this - I remember this on the IBM 6150.
Brett
#10
| |||
| |||
|
|
Perhaps as a tie breaker... R83 was case sensitive at TCL and in BASIC statements. *For data, dict items also perceived data in a case sensitive manner. *(Which is why we needed to do do the trick where MCT was both a conversion and a correlative in order to get nice output with case-insensitive filtering.) *Some MV systems/flavors are still like that. When a user enters data, IIRC R83 was even case sensitive at INPUT, which is why we needed to do this: INPUT YN IF YN = "Y" OR YN = "y" THEN ... Some systems are still finicky about that and for cross-platform mobility I still occasionally code like this: IF OCONV(YN,"MCU") = "Y" THEN ... Because some systems have UPCASE() and others UCASE(), I avoid the functions and go with the OCONV(). AP (maybe OA) introduced complete case insensitivity across the board, too much for some people, but for me and others it was perfect. *IIRC, GA R91 had this too, and other MV platforms were getting it at about the same time (1991). *Even today I still get hung up with freakin stupid casing issues in some platforms (U2 in particular) but in D3 I simply don't need to think about it, and that's why it's important. As Scott mentioned, D3 has controls that allow case-sensitivity to be implemented for keys, data, and in BASIC - to allow D3 to look as primitive as all of the other MV variants for sites that require it. With regard to "It was about the time of AP that someone dreamed up the idea that all Item IDs should be numeric." *I've never heard of such a thing. *Perhaps you dreamed that up? * T |
The idea the item ids should be numeric was thrown at me in a major
meeting with significant clients by the chief developer and owner of a
major Pick solutions company when I rejected their $40,000+ solution.
So I certainly did not dream it up.
As regards the case sensitivity issue for IDs it never came up for us
in the 10+ years prior to OA. and there is no mention of it in the
Pick Pocket Guide for 1986. However it may be that we simply put a
turn it off in the logon proc that I have long forgotten.
Case Sensitivity is appropriate in Data Entry in my opinion. As
pointed out it is easy enough to turn the entry. We have had an upper
case option in our data entry routines since the beginning which we
use for sort fields in particular.
As for the BASIC verb it does not compile items containing lower case
names on D3 . In fact I always used lower case for comments and upper
case for program commands, variables etc. and was completely tossed
when I included a DM,BP item and it did not compile with the BASIC
verb. Now I use the COMPILE verb and am getting used to
lowStartCamelCase. However until the first version 9 service pack
comes out I am steering clear of optimising as much as possible.
Having a system crash because all the users have been sucked up by a
poor closedown in optimised code is a royal pain.
I still wonder what the case situation was in Reality/Royale.
Of course back in those days we had data entry operators not typists
and nobody was flipping back and forth between Word, Excel, Email and
Pick so the cap lock went on and stayed on.
Now there is a question for all. When did we stop selling Lear
Siegler at al terminals. I do remember that the quality took a nose-
dive when they moved to Mexico from the Good Ol' US of A. Plus there
was a dreadful Canadian thing the name of which slips my mind. The
magnificent AWA VTE6 of course took a plunge with the company but was
still in use by airlines such as Qantas and others many years later.
Memories of so long ago! :-)
Peter McMurray
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.