At 06:34 PM 10/18/2006 -0400, Hal Kaplan wrote: ...
I read what you wrote a couple of times and frankly got confused. First you say that humans can easily handle mixed-case and then you say they shouldn't have to. Computers are computers and humans are humans, etc., etc. Well, this human happens to like case-sensitive stuff. Filenames, variable names, you name it. Yes, it requires a certain amount of discipline and attention to detail and occasionally could be troublesome. But it's worth it. If a techie cannot keep track of spelling, using mixed-case, maybe he should not be programming. IMHO, and with the utmost of respect, your position is a cop-out.
...
This has been going on a long time, and I agree we're not going to convince each other. But because you said my explanation was confusing, I'll try to clarify it better.
First and foremost, I believe the actual content of a file, when referenced by the file I/O system, should never be dependent on case. "ThisFile.txt" should not be a different file than "THISFILE.txt". Do you agree with that? If you don't agree, can you provide a reason why it would be useful to have 2 different files named like that?
Next, I believe the same thing regarding variables (compiler symbol tables, etc) the same way. A variable "myvar" should be the same as "MyVar" (e.g. sort of resolve to the same 'address' in the compiler symbol table). Do you agree with that? If you don't agree, do you have an example where it would be useful?
The above have nothing to do with what the user/developer 'sees'. They are how I believe the underlying systems should 'function'.
Now, moving on to what the user "sees", I believe: a) the system should preserve exactly what the user/developer typed in (e.g. source code or file name), b) when displaying data that a user/developer typed in, they should see what they originally typed. The reason I believe this is because I believe proper use of capitalization helps humans read text.
Preserving what the user/developer types is not the same as defining how a system operates. So, when I want to attach a file to an email, I can bring up the dialog and start typing the path info without worrying about the case - e.g. typing "c:\otherfiles\analysis\clientx\" would get me down the path "C:\OtherFiles\Analysis\ClientX\". In the on-screen display, I would see the latter (if that was the way I originally created the directory names), but in my typing I would not have to properly enter case to find it.
What I was trying to point out was that what a user/developer sees does not have to be governed by the way the filesystem/compiler works internally. And, specifically, in regards to file name case, and variable name case the filesystem/compiler should not force the user/developer to take the extra effort. The main reasons I believe this is because I can't think of a good, rational reason why I would ever want 2 different files named "thisfile.txt" and "THISFILE.txt" and actually allow different content in them. Likewise, I think a compiler that results in a variable "myvar" and "MyVar" referring to 2 different values will cause additional program/compiler errors and therefore additional development/maintenance effort. I don't know about you, but I still make typos from time to time.
Lastly, you say you like case-sensitive stuff. Ok, but now you're on a network and the other 90% of folks don't like messing with remembering exact case of filenames, etc. Wouldn't it be better to standardize on non-case-sensitivity? After all, you could continue to type your case-sensitive searches for files and get to what you want, and the other "Shift-key-challenged" folks wouldn't have to do that to get to the same file.
I doubt I've convinced you of anything, but does that clarify what I was trying to say?
-Charlie _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
