Namespace and Full Class Name
Namespace and Full Class Name
It is time to talk seriously about names in the common language runtime and ILAsm. So far, in Chapter 5, “Modules and Assemblies,” you’ve encountered only names that were in fact filenames and hence had to conform to well-known filename conventions. From now on, however, you’ll need to deal with names in general, so it will be important to know the rules.
ILAsm Naming Conventions
Names in ILAsm are either simple or composite. Composite names are composed of simple names and special connection symbols such as a dot. For example, System and Object are simple names, and System.Object is a composite name. The length of either kind of name in ILAsm is not limited syntactically, but metadata rules impose certain limitations on the name length.
The simplest form of a simple name is an identifier, which in ILAsm must begin with an alphabetic character or one of the following characters:
#, $, @, _
and continue with alphanumeric characters or one of the following:
?, $, @, _
These are examples of valid ILAsm identifiers:
-
Object
-
_Never_Say_Never_Again_
-
men@work
One obvious limitation on ILAsm identifiers: an ILAsm identifier must not match any of the (rather numerous) ILAsm keywords.
The common language runtime accepts a wide variety of names with very few limitations. Certain names—for example, .ctor (an instance constructor), .cctor (a class constructor), and _Deleted* (a metadata item marked for deletion during an edit-and-continue session)—are reserved for internal use by the runtime. Generally, however, the runtime is liberal about names. As long as a name serves its purpose—identifying a metadata item unambiguously—and cannot be misinterpreted, it is perfectly fine.
To cover this variety, ILAsm offers an alternative way to present a simple name: as a single-quoted literal. For example, these are valid ILAsm simple names:
-
'123'
-
'Space Between'
-
'&%!'
One of the most frequently encountered kinds of composite names is the dotted name, a name composed of simple names separated by a dot:
<dotted_name> ::= <simple_name>[.<simple_name>*]
Examples of dotted names include the following:
-
System.Object
-
'123'.'456'.'789'
-
Foo.Bar.'&%!'
Namespaces
Simply put, namespaces are the common prefixes of the full names of classes. The full name of a class is a dotted name; the last simple name it contains is the class name, and the rest is the namespace of the class.
It takes longer, perhaps, to explain what namespaces are not. Namespaces are not metadata items—they do not have an associated metadata table, and they cannot be referenced by tokens. Namespaces also have no direct bearing on assemblies. The name of an assembly might or might not match in full or in part the namespace(s) used in the assembly. One assembly might use several namespaces, and the same namespace can be used in different assemblies.
So why does the metadata model even bother with namespaces and class names instead of simply using the full class names? The answer is simple: economy of space. Let’s suppose that we define two classes with the full names Foo.Bar and Foo.Baz. Since the names are different, in the full-name model we would have to store two full names in the string heap: Foo.Bar\0Foo.Baz\0. But if we split the full names into namespaces and names, we need to store only Foo\0Bar\0Baz\0. This is quite a difference when you consider the number of possible classes.
Namespaces in ILAsm are declared in the following way:
.namespace MyNamespace {// Classes declared here // Have full name "MyNamespace.<simple_name>" }
Namespaces can be nested, as shown here:
.namespace MyNamespace {
Or they can be unnested. This is how the IL Disassembler represents namespaces in the disassembly text:
.namespace MyNamespace {
Full Class Names
As the preceding section explained, a full class name is a dotted name, composed of the class’s namespace and the name of the class. The loader resolves class references by their full names and resolution scopes, so the general rule is that no classes with identical full names should be defined in the same module. For multimodule assemblies, an additional (less strict) rule prohibits defining public classes—classes visible outside the assembly—with identical full names in the same assembly.
In ILAsm, a class is always referenced by its full name, even if it is referenced from within the same namespace. This makes class referencing context-independent.
The name of a class should be simple. Theoretically, a class name could contain a dot without violating metadata rules, but I recommend avoiding dotted class names, because they bring at best mild confusion.
ILAsm does not allow dotted names as class names, but you can bypass this restriction by quoting the dotted name, thus turning it into a simple name and avoiding a syntax error:
.namespace X { .class public 'Y.Z' {
And because a class is always referenced by its full name, a class with a dotted name will not pose any resolution problems (it will be referenced as X.Y.Z anyway), and the module will compile and work. But if you disassemble the module, you’ll find that the left part of the dotted name of the class has migrated to the namespace, courtesy of the metadata emission API:
.namespace X.Y { .class public Z {
Although this is not what you intended, it has no dire consequences—just a case of mild confusion. If you know and expect this effect, and don’t get confused that easily, you can even forgo the namespace declarations altogether and declare classes by their full names, to match the way they are referenced:
.class public 'X.Y.Z' {
The first release of the common language runtime imposes a limitation on the full class name length, specifying that it should not exceed 1023 bytes in UTF-8 encoding. The ILAsm compiler, however, does not enforce this limitation. Single quotes, should they be used for simple names in ILAsm, are a purely lexical tool and don’t make it to the metadata; thus they don’t contribute to the total length of the full class name.
EAN: 2147483647
Pages: 147