Much of the detailed information contained in Interface Repository objects is represented in the form of TypeCodes. TypeCodes are complex data structures whose actual representation is hidden. A TypeCode is an architected way of describing in complete detail everything that is known about a particular data type in the IDL language, regardless of whether it is a (built-in) basic type or a (user-defined) aggregate type.
Conceptually, every TypeCode contains a "kind" field (which classifies it), and one or more parameters that carry descriptive information appropriate for that particular category of TypeCode. For example, if the data type is long, its TypeCode would contain a "kind" field with the value tk_long. No additional parameters are needed to completely describe this particular data type, since long is a basic type in the IDL language.
By contrast, if the TypeCode describes an IDL struct, its "kind" field would contain the value tk_struct, and it would possess the following parameters: a string giving the name of the struct, and two additional parameters for each member of the struct: a string giving the member name and another (inner) TypeCode representing the member's type. This example illustrates the fact that TypeCodes can be nested and arbitrarily complex, as appropriate to express the type of data they describe. Thus, a structure that has N members will have a TypeCode of tk_struct with 2N+1 parameters (a name and TypeCode parameter for each member, plus a name for the struct itself).
A tk_union TypeCode representing a union with N members has 3N+2 parameters: the type name of the union, the switch TypeCode, and a label value, member name and associated TypeCode for each member. (The label values all have the same type as the switch, except that the default member, if present, has a label value of zero octet.)
A tk_enum TypeCode (which represents an enum) has N+1 parameters: the name of the enum followed by a string for each enumeration identifier. A tk_string TypeCode has a single parameter: the maximum string length, as an integer. (A maximum length of zero signifies an unbounded string.)
A tk_sequence TypeCode has two parameters: a TypeCode for the sequence elements, and the maximum size, as an integer. (Again, zero signifies unbounded.)
A tk_array TypeCode has two parameters: a TypeCode for the array elements, and the array length, as an integer. (Arrays must be bounded.)
The tk_objref TypeCode represents an object reference; its parameter is a repository ID that identifies its interface.
A complete table showing the parameters of all possible TypeCodes is given in the SOMobjects Base Toolkit Programmers Reference Manual; see the TypeCode_kind function of the Interface Repository Framework.
TypeCodes are not actually "objects" in the formal sense. TypeCodes are referred to in the CORBA standard as pseudo-objects and described as "opaque". This means that, in reality, TypeCodes are special data structures whose precise definition is not fully exposed. Their implementation can vary from one platform to another, but all implementations must exhibit a minimal set of architected behavior. SOM TypeCodes support the architected behavior and have additional capability as well (for example, they can be copied and freed).
Although TypeCodes are not objects, the programming interfaces that support them adhere to the same conventions used for IDL method invocations in SOM. That is, the first argument is always a TypeCode pseudo-object, and the second argument is a pointer to an Environment structure. Similarly, the names of the TypeCode functions are constructed like SOM's C-language method-invocation macros (all functions that operate on TypeCodes are named TypeCode_<function-name>). Because of this ostensible similarity to an IDL class, the TypeCode programming interfaces can be conveniently defined in IDL as shown below.
A complete table showing the parameters of all possible TypeCodes is given in the SOMobjects Developer Toolkit Programmers Reference Manual; see the TypeCode_kind function of the Interface Repository Framework.
interface TypeCode {
enum TCKind {
tk_null, tk_void,
tk_short, tk_long, tk_ushort, tk_ulong,
tk_float, tk_double, tk_boolean, tk_char,
tk_octet, tk_any, tk_TypeCode, tk_Principal, tk_objref,
tk_struct, tk_union, tk_enum, tk_string,
tk_sequence, tk_array,
// The remaining enumerators are SOM-unique extensions
// to the CORBA standard.
//
tk_pointer, tk_self, tk_foreign
};
exception Bounds {};
// This exception is returned if an attempt is made
// by the parameter() operation (described below) to
// access more parameters than exist in the receiving
// TypeCode.
boolean equal (in TypeCode tc);
// Compares the argument with the receiver and returns TRUE
// if both TypeCodes are equivalent. This is NOT a test for
// identity.
TCKind kind ();
// Returns the type of the receiver as a TCKind.
long param_count ();
// Returns the number of parameters that make up the
// receiving TypeCode.
any parameter (in long index) raises (Bounds);
// Returns the indexed parameter from the receiving TypeCode.
// Parameters are indexed from 0 to param_count()-1.
//
// The remaining operations are SOM-unique extensions.
//
short alignment ();
// This operation returns the alignment required for an instance
// of the type described by the receiving TypeCode.
TypeCode copy (in TypeCode tc);
// This operation returns a copy of the receiving TypeCode.
void free (in TypeCode tc);
// This operation frees the memory associated with the
// receiving TypeCode. Subsequently, no further use can be
// made of the receiver, which, in effect, ceases to exist.
void print (in TypeCode tc);
// This operation writes a readable representation of the
// receiving TypeCode to stdout. Useful for examining
// TypeCodes when debugging.
void setAlignment (in short align);
// This operation overrides the required alignment for an
// instance of the type described by the receiving TypeCode.
long size (in TypeCode tc);
// This operation returns the size of an instance of the
// type represented by the receiving TypeCode.
};
A detailed description of the programming interfaces for TypeCodes is given in the SOMobjects Developer Toolkit: Programmers Reference Manual.