Common Type System n The Module Subtitle Foundation

Common Type System n The Module Subtitle Foundation of Interoperability

Objectives n Motivations of the Common Type System (CTS) n Which types are defined in the CTS n How inheritance is implemented n What type safety is n See a sample of language interoperation

Contents n Section 1: Overview n Section 2: Typology n Section 3: Anatomy n Section 4: Putting it all together

Section 1: Overview n What are types? n Who has types? n Why have types?

Looking Back n n Why have types at all? n Typeless vs. typed language n Type vs. instance Each language brings its own type system n n Different types on different platforms Need for common types for interoperation n IDL uses smallest common denominator

The Unknown Type n n What is a “Type” in the Object Oriented World? n Allowable values n Operations defined Notions in the Common Type System: n Types are different n n Types implement the same interface n n . . . if they have different representations. . . if they responds to the same set of messages Types are identical n . . . if they have the same representation n . . . and respond to the same messages

Locations n n Values are stored in locations n Local variables n Parameters n A storage place with a name n A location can hold a single value at a time Locations have a well defined type n Type defines which values can be stored n n The value must be assignment compatible to the location Type defines usage of value

Contracts n n n Specify requirements on implementation of a type n Type states which contracts must be supported n Contracts are shared assumptions on set of signatures Signatures define constraints on. . . n Types, locations, parameters, methods, etc n Define which values can be stored n Enumerate allowed operations Signatures are the enforceable part of a contract n Implementation of a type can be verified

Coercion n Assignment incompatible value must be converted n Widening coercion n Never loses information n Usually implemented as implicit conversion Narrowing coercion n Information might be lost n Usually implemented as explicit conversion Coercion changes the value

Casting n A value has the type of its location n Casting allows use of value as if it had different type n Usually casting is a compile time operation n n Unless exact type of value is unknown n Runtime check might result in exception Casting does not change the value or its type

The Common Language Specification n n Set of rules for interoperability n „Subset“ of the Common Type System n Large enough to be expressive n Small enough that all languages can accommodate it n Guideline was only to include verifiable constructs Only applies to types that are externally visible n n Assumes assemblies as subjects of interoperability Identifiers must follow certain rules n Case sensitivity

Section 2: Typology n What kind of types are there? n Which types are defined in the CTS? n What makes up a type?

Value vs. Reference n n Value types n Represented by sequence of bits in a location n Common built-in data types Reference types n Represented by a location and a sequence of bits n Objects, Interfaces, Pointers

Built-In Value Types n n Integer values n int 8, int 16, int 32, int 64 n unsigned counterparts Super long decimal value n n Floating point values n n float 32, float 64 Unicode character value n n decimal (28 digits) char Boolean value n bool

Built-In Reference Types n n Object n Base class for all types n Allows for polymorphism across all types String n Can hold up to 231 characters n Is immutable n Changing creates new modified string

Boxing and Unboxing n Value types can be boxed and unboxed n Boxing allows value types to travel by-ref n Based on object-ness of all types 42 42 42 Boxed: Reference double Value; // Boxing object Boxed. Value = Value; // Unboxing Value = (double)Boxed. Value; Unboxed: Copy

Enumerations n Defines a set of values of an underlying type n Underlying type can be any integer type n Fields are static literals representing a constant n Value assigned by compiler n Multiple fields can be assigned the same value n One is marked as the primary field n Underlying type is assignment compatible n Can call methods of underlying type on enum type n Still different types when used as actual parameters

Exceptions n When exception occurs an object is created n n Subclass of System. Exception Protected block for exception handling : try n Protected blocks may be nested n If exception occurs CLR searches for handler n Four kinds of handlers: n Catch handler filters type of exception object n Filter handler determines if exception can be handled n Fault handler executes when exception occurs n Finally handler executes whenever protected block is left

Delegates and Events n Delegates n Similar to function pointers found in C, C++ n n n Use is type safe Multicast delegates call more than one method n Derive from System. Multicast. Delegate n Result of Combine method is Multicast. Delegate to call Events n Change of state of an object n Observer registers delegate with event as handler n Event triggers Multicast. Delegate when it is fired

Attributes n User-defined annotations to the metadata n An instance of a type is stored along with metadata n Declarative access to functionality n Can be of any type n n Mostly derived from System. Attribute CLR predefines some attribute types n Control of runtime behavior

Pointer Types n n n Pointer contains address of memory location n Pointers are typed n Defined by specifying location signature Type safe operations defined n Loading the value from the location n Storing assignment compatible value to the location Address arithmetic is considered type unsafe n Such unmanaged pointers are not part of the CLS

Section 3: Anatomy n Type members n Type names n Visibility and Accessibility n Inheritance

Type members 1/2 n Allowable values of type may have substructure n Representation may be subdivided n Named sub-values are called fields n n Indexed sub-values are called array elements n n Type is called compound type Type is called array n Each field or element is typed n Array elements all have same type n These types do never change Type may declare static fields n Locations associated with type – not with instance

Type Members 2/2 n Methods are operations n Defined to operate on the type: static method n Defined operate on an instance n n Method is passed the instance to operate on : this Instance vs. virtual method n Both methods may be overridden n Instance method is called on declared type n n Determined at compile time Virtual method is called on exact type n Determined at runtime

Valid Names n Each entity of the type system is given a name n n There is only one name for an entity Must be unique in a certain scope for a certain kind n Methods, fields, nested types, properties, events n The CLS demands uniqueness in scope n Scope qualifies the name n Types are scoped by implementing assembly n Type indistinct alias (typedef) is not supported

Visibility and Accessibility n Type must be visible to be referenced n Access to type member requires three conditions n n Type must be visible n The member must be accessible n Security demands are granted Six degrees of accessibility n Private, family, assembly, family and assembly n Family or assembly, public n Interface members are always public n Overriding methods may only widen accessibility n Not under CLS!

Type Inheritance n Inheriting type supports all the contracts of base type n n May support additional or modified functionality All object types inherit explicitly or implicitly n Except System. Object which is the root n Objects have a single base class n Objects can implement several interfaces

Member Inheritance n All non-static fields are inherited n n n Visibility and accessibility determine access All instance and virtual methods are inherited n Constructors and static methods are not n Non-virtual and static methods may be hidden n Virtual methods may be marked as final Properties and events are not inherited

Section 4: Putting it together n Sample cross language inheritance n Define a class in C# n Derived from it via Visual Basic n Derive again from Managed C++

Grandfather in C# using System; namespace Smith { public class Grandfather { public Grandfather() { Name = "Smith"; First. Name = "Grand. Dad"; } public string Name; public string First. Name; public virtual int Age() { return(85); } }; };

Father in Visual Basic. NET Imports System; Namespace Smith Public Class Father Inherits Grandfather Public Sub New() First. Name = "Father" End Sub Public Overrides Function Age() As Integer Age = 45 End Function End Class End Namespace

Son in Managed C++ #using <mscorlib. dll> using namespace System; #using "Father. dll" namespace Smith { __gc public class Son : public Father { public: Son() { First. Name = S"Son"; } int Age() { return(5); } }; };

Summary n Interoperability achieved through: n Base types n Concept of object-ness n Notion of inheritance n Event model n Exception handling

Questions?