Framework Design Guidelines: Case Sensitivity

Continuing in the series of discussing topics from the Framework Design Guidelines

 

Expert from 3.1.4 Case Sensitivity

 

Languages that can run on the CLR are not required to support case sensitivity,

although some do. Even if your language supports it, other languages

that might access your framework do not. Any APIs that are

externally accessible, therefore, cannot rely on case alone to distinguish

between two names in the same context.

DO NOT assume that all programming languages are case sensitive.

They are not. Names cannot differ by case alone.

 

PAUL VICK When it came to the question of case sensitivity, there was

no question in the minds of the Visual Basic team that the CLR had to support

case insensitivity as well as case sensitivity. Visual Basic has been case

insensitive for a very long time, and the shock of trying to move VB developers

(including myself) into a case-sensitive world would have made any

of the other challenges we faced pale in comparison. Add to that the fact

that COM is case insensitive, and the matter seemed pretty clear. The CLR

would have to take case insensitivity into account.

 

JEFFREY RICHTER To be clear, the CLR is actually case sensitive. Some

programming languages, like Visual Basic, are case insensitive. When the

VB compiler is trying to resolve a method call to a type defined in a case sensitive

language, like C#, the compiler (not the CLR) figures out the

actual case of the method’s name and embeds it in metadata. The CLR

knows nothing about this. Now, if you are using reflection to bind to a

method, the reflection APIs do offer the ability to do case-insensitive lookups.

This is the extent to which the CLR supports case.