On Wed, 23 Mar 2005 22:49:15 +0100, Alexander Gräf wrote:

>> -----Ursprüngliche Nachricht-----
>> Von: Kjell Rilbe [mailto:kjell.rilbe@...]
>> Gesendet: Mittwoch, 23. März 2005 13:57
>> An: firebird-support@yahoogroups.com
>> Betreff: Re: [firebird-support] Use of double quoted names in Firebird
>>
>> In C++, if you do a typo (including wrong case), it is also
>> caught as soon as you try to compile. Due to C++ complexity
>> the error message might be slightly more difficult to
>> decipher, but once that problem is solved you just correct
>> the typo and try again. Problem probably solved in less than a minute.
>
>In addition, most IDEs have syntax highlighting, code completion ("IntelliSense") and error highlighting which makes writing and trouble shooting really easy. VS.NET also checks syntax while you're typing, and highlights errors without compiling (at least the syntax errors).
>
>> In SQL, if you do a typo in a query, it will be caught with a
>> usually pretty clear and helpful error message the first time
>> the query is prepared. You correct the typo and try again. If
>> you change a query, you'd better try to execute it at least
>> once before putting it into your production environment,
>> otherwise you're a lunatic. If you do, you will find the typo
>> and correct it. Problem solved in less than a minute.
>>
>> For SP:s, it's even better, because then the typo will be
>> detected by the SP compiler immediately when you try to
>> (re)create the SP. Problem solved in 10 seconds.
>
>Database-IDEs also have auto-completion, so it has become a lot easier, even in brazil.
>
>> In all these scenarios I just can't see why case typos would
>> cause such endless extra problems compared to any other kind
>> of typo.

------------------------>

>They don't: If case does not matter, it does not matter. If it does matter, it will matter very soon, in most cases while compiling. It don't like the current solution, because those quotes aren't nice to type, and without them, the DB will not only store any metadata UPPERCASED, it will also make no distinction in cases. Using quotes is the only option for people who want to have case sensitivity and i18n in identifiers, because the current model of case insensitivity in unquoted identifiers cannot be changed. But currently, the case insensitivity is anywhere but near perfect, because as Kjell has stated, his language includes many letters which do, if uppercased, map to very unusual letters. And I'm pretty sure some eastern languages don't have lower-/UPPERcase at all.

<------------------------

I love the actual model of case insensitiveness at identifiers unquoted
FB e MSSQL.
The last thing I want is to disrupt a application because I put a N
instead of a n in the
name of a column, among 700 stored procedures.
This is the kind of preciosism I hate. Case of identifiers is a
aesthetic choice of convenience.
And should stay that way.

--------------------->

>However, I think case sensitive identifiers are a good thing, and anyone argueing that FirstName is the same thing as Firstname should go back to gradma and play some memory. People who are actually not able to remember the case of their identifiers should not program at all, because case issues are not the only typos that can be done, and actually not the most hard ones to spot in the code.

<---------------------

For me FirstName and Firstname is the same silly thing. The only diff
is aesthetic.
Aesthetic differences should not cause harm.


----------------------->

>The discussion would directly lead into demanding a fuzzy-logic, error-tolerant SP- and query-compiler, which will also forgive about typos, like interchanged letters, wrong letters and wrong identifiers at all. Why dont we simply fix at saying, "the compiler should look for the nearest identifier that can be found, no matter how great the distance between the written and the stored identifier is". I also would suggest a semantically parsing compiler, which automatically maps "LastName" automatically to "Surname". Argument? They mean the same, which is the same argument as telling people "LastName" and "Lastname" are the same.

<----------------------

Case is a *AESTHETIC* convenience. And the other things is just
exageration out of reality.
LastName carries the same data and meaning to the system as Lastname,
the difference is just
you forgot the last N in a spot inside 30 thousand lines of something.
Shoud the compiler would issue a error? Absolutely NOT, it's SILLY.
As the Surname = LastName question, although synonym, if you use
LastName so retain it. If you
use Surname, use it to the last line. And in *that* case the compiler
must throw a error.





-------------->

>BTW: I would like to see the DB at least store the identifiers exactly as I have written them, even if I wrote them without quotes. That's only a cosmetic issue, I know, but everybody will agree that FirstName does not look as cluttered as FIRSTNAME. Using underscores is currently the only option to make it a little bit more readable, and readable code is - as we all know - a very important issue.

<---------------

Finnaly, something useful... I agree with it.