Foundation classes
Microsoft Axapta is built on application code written in an advanced
programming language called X++. This language is inspired by Java, but
has been augmented to deal with the specific chores that are relevant
in writing software for the enterprise.
X++ supports many native data types, like integer, real, date etc. However,
there are few higher-level data types that are useful for aggregating
values of simpler types. The only such types available in X++ are arrays
and containers, and even these have their shortcomings: Objects, that
are the base of an object oriented language, may not be stored in arrays
or containers.
The Microsoft Axapta Foundation Classes remedy this situation. They
are general purpose, production quality classes used to aggregate other
values. The classes are implemented in C++ in order to achieve the maximum
performance. The classes are built using state-of-the-art technology that
has been tried and tested in the industry for a long time.
Currently the following classes are implemented: Lists,
maps, sets, arrays,
and structs.
The Axapta Foundation classes
The Microsoft Axapta foundation classes currently fall in five distinct
parts: Sets, maps, lists, arrays and structs.
Each of the foundation classes are generic in the sense that they work
on any Microsoft Axapta type. In order to express this using X++ syntax
the special type “any” is used to represent values. A value of type any
may assume values of any of the specific X++ types. When objects of any
of the foundation classes are instantiated, the types of the constituent
elements are given in the constructor, in the form of a value of the enumeration
type called (appropriately) types.
Each of the
foundation classes may be used form more complex classes. For instance,
a stack may easily be implemented using a list where the elements are
always added to the start of the list (which then becomes the top of the
stack). The classes may also be extended for whatever purposes the programmer
may have in mind, for instance to supply more meaningful names for the
types within the application context. Thus, the user may extend the list
class to create s list of Customer records, where the operations could
be made type safe (accepting only Customer records, not any record).