This conversation is partially off-topic - although still applicable
to IBO in the sense that IBO supports quote delimited identifiers very
well.

> I'll challenge the "subjective" notion, however. It
> is two extra characters to type every time you refer
> to the object and you have to remember to put them
> there.

If it is less keystrokes we are after then lets go back to using 8
character names.

> same scope in C, fred, FRED and Fred doesn't mean
> you should...just because you can put blanks in column
> names in some databases doesn't mean it's a good idea...
> just because some databases let you have columns or tables
> named STATE or TYPE doesn't mean you should. This is
> not subjective, it's plain common sense.

Its easy enough to choose bad names even without case sensitivity -
and its even harder to distinguish the names in code when everything
gets converted to uppercase by IB.

"Type" may be a bad name, but SUBJECT_TYPE or "Subject Type" are
possibly good names (context is everything). The difference being
that with SUBJECT_TYPE I have to provide an appropriate title/label
with ever control, grid, report etc that I write. With "Subject Type"
I get to take advantage of the provided automation. I also happen to
like the way the names show up in my syntax highlighting editor. This
is why I *subjectively* like quote delimited identifiers.

To quote myself...

> If you like quoted identifiers use them, I do. If you
> dont like them then dont use them. IBO makes either
> choice valid and easy to implement.

You still get to choose good or bad programming practices, but there
is nothing inherently wrong with using quote delimited identifiers.


Geoff Worboys
Telesis Computing