Class Augmentation

Class Augmentation

In ILAsm, as in Microsoft Visual Basic .NET and Visual C# .NET, all members, attributes, and nested classes of a class are declared within the lexical scope of that class. However, ILAsm, unlike Visual Basic .NET and Visual C# .NET, allows you to reopen a once-closed class scope and define additional items:

   .class public X extends Y implements IX,IY {           }        // Later in the source, possibly in another source file...    .class X {        // More items defined    }

This reopening of the class scope is known as class augmentation. A class can be augmented any number of times throughout the source code, and the augmenting segments can reside in different source files. The following simple safety rules govern class augmentation:

• The class must be fully defined within the module—in other words, you cannot augment a class that is defined somewhere else.

• Class flags, the extends clause, and the implements clause must be fully defined at the lexically first opening of class scope, because these attributes are ignored in augmenting segments.

• None of the augmenting segments can contain duplicate item declarations. If you declare field X in one segment and then declare it in another segment, the ILAsm compiler will not appreciate the fact that you probably have the same field in mind and will read it as an attempt to define two identical fields in the same class, which is not allowed.

• The augmenting segments are not explicitly numbered, and the class is augmented according to the sequence of augmenting segments in the source code. This means that the sequence of class item declarations will change if you swap augmenting segments, which in turn might affect the class layout.

A good strategy for writing an ILAsm program is to use forward class declaration, explained in the Chapter 1 section “Forward Declaration of Classes.” This strategy allows you to declare all classes of the current module, including nested ones, without any members and attributes and to define the members and attributes in augmenting segments. This way, the ILAsm compiler gets the full picture of the module’s type declaration structure before any type is referenced. By the time locally declared types are referenced, they all are already defined and have corresponding TypeDef metadata records.

Manifest declarations, described in Chapter 5, followed by forward class declarations look a lot like a program header, so I would not blame you if you put them in a separate source file. Just don’t forget that this file must be first on the list of source files when you assemble your module.