CHAPTER 1 THE PHILOSOPHY (Photo web hosting) OF .NET 19
CHAPTER 1 THE PHILOSOPHY OF .NET 19 Understanding the Common Language Specification As you are aware, different languages express the same programming constructs in unique, languagespecific terms. For example, in C# you denote string concatenation using the plus operator (+), while in VB .NET you typically make use of the ampersand (&). Even when two distinct languages express the same programmatic idiom (e.g., a function with no return value), the chances are very good that the syntax will appear quite different on the surface: ‘ VB .NET method returning nothing. Public Sub MyMethod() ‘ Some interesting code… End Sub // C# method returning nothing. public void MyMethod() { // Some interesting code… } As you have already seen, these minor syntactic variations are inconsequential in the eyes of the .NET runtime, given that the respective compilers (vbc.exe or csc.exe, in this case) emit a similar set of CIL instructions. However, languages can also differ with regard to their overall level of functionality. For example, a .NET language may or may not have a keyword to represent unsigned data, and may or may not support pointer types. Given these possible variations, it would be ideal to have a baseline to which all .NET-aware languages are expected to conform. The Common Language Specification (CLS) is a set of rules that describe in vivid detail the minimal and complete set of features a given .NET-aware compiler must support to produce code that can be hosted by the CLR, while at the same time be accessed in a uniform manner by all languages that target the .NET platform. In many ways, the CLS can be viewed as a subset of the full functionality defined by the CTS. The CLS is ultimately a set of rules that compiler builders must conform to, if they intend their products to function seamlessly within the .NET universe. Each rule is assigned a simple name (e.g., CLS Rule 6 ) and describes how this rule affects those who build the compilers as well as those who (in some way) interact with them. The cr me de la cr me of the CLS is the mighty Rule 1: Rule 1: CLS rules apply only to those parts of a type that are exposed outside the defining assembly. Given this rule, you can (correctly) infer that the remaining rules of the CLS do not apply to the logic used to build the inner workings of a .NET type. The only aspects of a type that must conform to the CLS are the member definitions themselves (i.e., naming conventions, parameters, and return types). The implementation logic for a member may use any number of non-CLS techniques, as the outside world won t know the difference. To illustrate, the following Add() method is not CLS-compliant, as the parameters and return values make use of unsigned data (which is not a requirement of the CLS): public class Calc { // Exposed unsigned data is not CLS compliant! public ulong Add(ulong x, ulong y) { return x + y;} }
Please visit our professional web hosting services to find out about cheap and reliable webhost service that will surely answer all your demands.