|
|
Posted by Adam Harvey on 07/27/06 08:47
On Thu, 27 Jul 2006 09:04:34 +0100, Tony Marston wrote:
> Having case-sensitive software causes more problems that it solves,
> therefore it is EVIL!
How do you propose to deal with different alphabets and languages? It's
not uncommon for programming languages to allow variable names to be in
something other than US-ASCII -- indeed, this code (if saved as UTF-8, at
least; I can't vouch for other encodings) works in PHP, since it allows
variable names to include high-bit characters:
<?php
$ουσ = 'foo';
printf("%s\n", $ουσ);
?>
The way I see it, there's four options:
1. Handle all alphabets with a concept of case in a case-insensitive
manner -- this requires a large database of knowledge within the
interpreter/compiler on how to normalise the case of each alphabet *and*
is going to have an impact on execution time in a non-compiled language,
since it's no longer just the Latin case of two comparisons and a
subtraction of 32 to normalise case.
2. Handle the Latin alphabet as a special case and do everything else on a
byte-by-byte (ie case-sensitive) basis, which provides inconsistency for
bilingual programmers coming from non-Latin alphabets.
3. Handle everything in a case-sensitive way, thereby avoiding all the
problems and also saving cycles that would have to be used to normalise
the identifier's case.
4. Just don't allow identifiers to use anything other than [a-zA-Z0-9_].
Bad for a lot of programmers in non-English speaking countries.
In an exclusively ASCII (or EBCDIC, or any other character set that only
provides the basic Latin alphabet) environment, case-insensitivity *may*
be a win for programmers (and being used to the
variableName/ClassName/CONSTANT convention myself, I'm not so sure about
that), but the moment programming languages leave the cocoon of Western
European languages, I don't see how variable names can be sanely handled
in a case-insensitive way.
Adam
--
Adam Harvey
To e-mail: don't make an example out of me!
Navigation:
[Reply to this message]
|