Vassili Bykov writes:
>Note however, that case does play a semantic role in variable names:
>capitalization determines a variable scope.  In a language with
>case-sensitive variable names, it is quite natural to expect
>case-sensitive func... oops, selectors -- if only for the sake of
>consistency.

I agreed.  However, in Smalltalk, one can define an instance (or class)
method with capital letter which can be very confusing and certainly not
"consistent" from the point of semantic role in variable names.  Smalltalk
method's case tell you nothing about its scope.

>Finally, case sensitivity might simply be a matter of someone's
>personal concept of The Right Thing (tm).

Yes or no.  The reason I brought this thing up is because I don't just use a
language.  I also want to understand why a particular "feature" was
implemented.  This can help me to more effectively use a language if I
understand the design and the philosophy behind it.  It is a pity if the
existence of a lanaguge's feature is due to the fact that traditionally that
particular feature is implemented the same way in other languages without
considering the language's own unique capabilities and nature. In order to
improve a language, it needs to be evolved to a better one.  In this case, I
just don't understand why Smalltalk method has to be case sensitive while I
can think of a stronger case for it being case-insensitive. That's why I ask
for design rationale behind it.  This is probably a tiny little issue for
99.9% of people that is not worth discussing but in my work the case
sensitive and its ambiguity affect some of my design decisions.

Thanks for your comment.



--
Mark Wai
Frontier Systems Architecture Inc.	
mailto: mwai at ibm.net or:[ mwai at frontiersa.com]       
__