Nbsp;   The Common Type System

By now, it should be obvious to you that the CLR is all about types. Types expose functionality to your applications and other types. Types are the mechanism by which code written in one programming language can talk to code written in a different programming language. Because types are at the root of the CLR, Microsoft created a formal specification—the Common Type System (CTS)—that describes how types are defined and how they behave.

The CTS specification states that a type can contain zero or more members. In Part II, “Designing Types,” I’ll cover all of these members in great detail. For now, I just want to give you a brief introduc- tion to them:

■ FieldA data variable that is part of the object’s state. Fields are identified by their name

and type.

■ MethodA function that performs an operation on the object, often changing the object’s state. Methods have a name, a signature, and modifiers. The signature specifies the number of parameters (and their sequence), the types of the parameters, whether a value is returned by the method, and if so, the type of the value returned by the method.

■ PropertyTo the caller, this member looks like a field. But to the type implementer, it looks like a method (or two). Properties allow an implementer to validate input parameters and object state before accessing the value and/or calculating a value only when necessary. They also allow a user of the type to have simplified syntax. Finally, properties allow you to create read-only or write-only “fields."

■ EventAn event allows a notification mechanism between an object and other interested ob- jects. For example, a button could offer an event that notifies other objects when the button is clicked.

The CTS also specifies the rules for type visibility and access to the members of a type. For ex- ample, marking a type as public (called public) exports the type, making it visible and accessible to any assembly. On the other hand, marking a type as assembly (called internal in C#) makes the type visible and accessible to code within the same assembly only. Thus, the CTS establishes the rules by which assemblies form a boundary of visibility for a type, and the CLR enforces the visibility rules.

A type that is visible to a caller can further restrict the ability of the caller to access the type’s members. The following list shows the valid options for controlling access to a member:

■ PrivateThe member is accessible only by other members in the same class type.

■ FamilyThe member is accessible by derived types, regardless of whether they are within the same assembly. Note that many languages (such as C++ and C#) refer to family as protected.

■ Family and assemblyThe member is accessible by derived types, but only if the derived type is defined in the same assembly. Many languages (such as C# and Visual Basic) don’t offer this access control. Of course, IL Assembly language makes it available.

■ AssemblyThe member is accessible by any code in the same assembly. Many languages refer to assembly as internal.

■ Family or assemblyThe member is accessible by derived types in any assembly. The mem- ber is also accessible by any types in the same assembly. C# refers to family or assembly as protected internal.

■ PublicThe member is accessible by any code in any assembly.

In addition, the CTS defines the rules governing type inheritance, virtual methods, object lifetime, and so on. These rules have been designed to accommodate the semantics expressible in modern- day programming languages. In fact, you won’t even need to learn the CTS rules per se because the language you choose will expose its own language syntax and type rules in the same way that you’re familiar with today. And it will map the language-specific syntax into IL, the “language” of the CLR, when it emits the assembly during compilation.

When I first started working with the CLR, I soon realized that it is best to think of the language and the behavior of your code as two separate and distinct things. Using C++/CLI, you can define your own types with their own members. Of course, you could have used C# or Visual Basic to define the same type with the same members. Sure, the syntax you use for defining the type is different de- pending on the language you choose, but the behavior of the type will be identical regardless of the language because the CLR’s CTS defines the behavior of the type.

To help clarify this idea, let me give you an example. The CTS allows a type to derive from only one base class. So, although the C++ language supports types that can inherit from multiple base types, the CTS can’t accept and operate on any such type. To help the developer, Microsoft’s C++/CLI com- piler reports an error if it detects that you’re attempting to create managed code that includes a type deriving from multiple base types.

Here’s another CTS rule. All types must (ultimately) inherit from a predefined type: System.Object.

As you can see, Object is the name of a type defined in the System namespace. This Object is the root of all other types and therefore guarantees that every type instance has a minimum set of behav- iors. Specifically, the System.Object type allows you to do the following:

■ Compare two instances for equality.

■ Obtain a hash code for the instance.

■ Query the true type of an instance.

■ Perform a shallow (bitwise) copy of the instance.

■ Obtain a string representation of the instance object’s current state.

Date: 2016-03-03; view: 609