CLS allows private portions of the code in classes to be non CLS compliant. How is this possible, because ultimately the code needs to be converted to the IL ?
views:
76answers:
4
+5
Q:
CLS allows private portions of the code in classes to be non CLS compliant. How is this possible ?
+7
A:
CLS stands for Common Language Specification. To simplify, it's basically the minimal types and identifiers that all .NET languages must know. For example, Int32 is CLS-compliant: any .NET language must be able to handle it. UInt32 is not. Since your code is private, it won't be accessed by other assemblies in other languages so it doesn't matter if it is CLS-compliant or not.
See this MSDN page for more information about CLS-compliance.
Edit: I think you misunderstand what CLS compliance is. It's not about whether the code can be compiled into IL or not. UInt32 can be used in IL. So does an identifier named '©'. CLS-compliant is just a minimal contract for language interoperability. What the CLR supports is way broader than the limitations for CLS compliance.
Edit2: Yes, you're right. A .NET language is required to support Int32, not UInt32, even if has a direct mapping to IL. See pointers, they're supported in IL and in C# but are not CLS compliant. VB.NET doesn't implement a support for them and still is CLS-compliant.
Julien Lebosquain
2010-05-29 10:05:09
What I understand is : If something is CLS comliant, then it is because IL supports that, because everything will be converted to IL when compiled. When UInt32 is not CLS compliant, then what does it matters whether it is in the private implementation or public, because there is no way it will be compiled to IL ?
Puneet Dudeja
2010-05-30 05:56:29
Sorry, I think I am asking ridiculous questions, but if UInt32 is supported by CTS(i.e by IL also), then why they have made it non CLS compliant ? That is, if I return an UInt32 from one of my methods in one language then why cannot another language call this method and accept the return value? Can another language not directly use System.UInt32 and there is no need of its compiler to support a data type that will map to UInt32 of .net framework ?
Puneet Dudeja
2010-05-30 17:18:32
+1
A:
No - The CLR does not need to know what's happening under the hood. You need to have only your public classes and public/private members of those public classes to be CLS compliant, rest code will never be accessed - it will remain inaccessible to other languages that use your classes.
this. __curious_geek
2010-05-29 10:07:52
e.g. variables are case sensitive in visual basic, and i take two variables with case differences only, which is not cls compliant and put these in the scope of a private function. Now when i run my application, it will be converted into IL. Now, when IL does not support variables with case differences only, these two diff variables will be taken as a single same variable.
Puneet Dudeja
2010-05-29 10:27:24
CLS says, The code should not expose any two names (identifiers) that differ only in their case. And VB.Net compiler does not let you compile the source saying - `Local variable is already declared in the current block.`
this. __curious_geek
2010-05-29 10:40:01
+1
A:
The CLS's only real goal is to ensure that any compliant language is able to interact with any compliant class, regardless of the language it was written in, cause that class's API by definition requires only things that all languages must support. Hence, "Common Language Specification".
Semi obviously, the private API is (or at least, should be) invisible outside your own code, so it doesn't matter whether it's CLS compliant or not.
cHao
2010-05-29 11:04:13
+1
A:
If it's CLS compliant that means every .NET language must support it.
If it is representable in IL that means that some .NET languages may support it.
One represents a requirement of .NET languages and the other represents what is possible in .NET languages.
Davy8
2010-05-30 17:40:20