The general categories of .NET types supported by ABL include:
All primitive data types — These data types are defined by and used only by .NET languages, and represent atomic data types of the language—for example, the C# bool and double or the Visual Basic Boolean and Double data types. An ABL application accesses these primitive data types through public .NET method parameters, properties, or data members, using corresponding built-in ABL primitive types according to ABL-defined mappings—for example, the corresponding ABL LOGICAL and DECIMAL. ABL respects these mappings by doing appropriate compile-time type checking and run-time overflow checking.
Most object types — These include most of the types that derive from the .NET class, System.Object. .NET supports two basic kinds of object types:
Value types — Objects that .NET assigns and passes by value. When .NET passes or assigns a value type object, the destination receives a unique and separate copy of the object.
Reference types — Objects that .NET assigns and passes by reference. When .NET passes or assigns a reference type object, the destination receives a reference to the same copy of the object.
The .NET CLR treats a small subset of value and reference object types as aliases for corresponding primitive data types of CLS-compliant languages. These languages can access the same values interchangeably as either the primitive data types that they define, or as the corresponding alias object types that .NET defines (for example in C#, as either int or System.Int32). ABL also interchangeably accesses (through assignment or parameter passing) either a given .NET primitive type or its alias object type as a given ABL primitive type by automatically mapping to that ABL type (for example, in this case, INTEGER). Thus, ABL views a .NET primitive type and its alias object type as a single ABL primitive type. This documentation therefore refers to both the .NET primitive data types and their corresponding alias object types as .NETmapped data types. Where applicable, it also refers to the object-type equivalents, themselves, as .NETmapped object types.
Note: .NET aliasing between primitive and object types differs from the mapping between ABL primitive and .NET types. In .NET, a given primitive type and its alias object type are treated as the same type. In ABL, the mapping between a given .NET type and its corresponding ABL primitive type involves a conversion between the two types. So, when a given value is converted between the corresponding ABL and .NET type, the precision, magnitude, or storage size might differ between the two.
.NET also supports automatic assignment and parameter passing between .NET primitive types (including their alias object types) and the .NET root object type, System.Object. This automatic assignment is done using a mechanism referred to as boxing (when the primitive type is assigned to a System.Object) and unboxing (when an appropriate System.Object is assigned to its corresponding primitive type). ABL also supports a similar form of boxing and unboxing for assignments and parameter passing between ABL primitive or array types and a .NET System.Object or .NET array object type. For more information, see .NET boxingsupport.
ABL treats all .NET value and reference types, other than the mapped data types, as objects similar to ABL class and interface types. The following sections describe these two kinds of object types and their basic function in ABL. For more information on ABL support for .NET types, see GeneralABL support for .NET types.
All primitive data types — These data types are defined by and used only by .NET languages, and represent atomic data types of the language—for example, the C# bool and double or the Visual Basic Boolean and Double data types. An ABL application accesses these primitive data types through public .NET method parameters, properties, or data members, using corresponding built-in ABL primitive types according to ABL-defined mappings—for example, the corresponding ABL LOGICAL and DECIMAL. ABL respects these mappings by doing appropriate compile-time type checking and run-time overflow checking.
