Re: case sensitivity

[Rob Myers <robmyers@xxxxxxx>]

On Sunday, March 2, 2003, at 11:56 PM, jm wrote:

> this sounds like an argument for designing goo in a vacuum. however,
> I don't think we can ignore the computing landscape in which goo has
> to operate.

I agree, but there are different ways of respecting the prevailing 
landscape. C wasn't designed with line numbers to aid Fortran 
interoperability. :-)

> the fact is that a very large number of libraries are
> written in c and some of them will use bad coding standards and
> some of these will need to be wrapped. I consider wrapping a library
> for use in goo as part of the 'goo experience' so weaknesses in
> wrapper generators are weaknesses in goo.

Mapping names is a strong solution. The "melange" interface generator 
for Dylan handles this explicitly. You can change names, prefix them, 
mangle them, do whatever. If the only difference between two macros or 
a function and a constant is the case, this is a design decision that 
is easy to represent using name mapping. As I mentioned, it's also 
probably bad design and this is a good opportunity to "correct" it. :-)

So
#define VERSION		Version()
int Version()			{ return version; }
void Version( int v )		{ version = v; }
const int version = 1;

can be mapped as any of:

kVERSION, $VERSION, VERSION-define
Version(), GetVersion(), Version-getter()
Version2(), SetVersion(), Version-setter()
gVersion, *version*, version-global,

> now lets consider the benefits of case insensitivity.
> robustness.

If you make a mistake in case you don't have to grep for the correct 
casing.
You aren't tempted to use case alone to differentiate similar bindings.

> useability.

Case-insensitive file systems are easier to use and search (for 
newbies), although I recognize they have their security problems. 
AppleScript, a language designed for end-users, is case-insensitive 
(although the IDE "corrects" your casing to match the first occurrence 
of an identifier).

> historical.

Lisp and Dylan are case insensitive.

- Rob.