|
ARON (ArmarX Object Notation) is the ArmarX implementation of variants which can be transferred over the network via ZeroC Ice. Further, ARON is the data representation used in the ArmarX Memory System. We distinguish between:
An ARON type specification defines the static type for an ARON data DTO or an ARON data object. It does not contain any data (e.g. an ARON type list only knows the accepted type, not the list members). Since ARON supports maybe types (raw ptr, smart ptr, optional), every ARON type DTO contains a special member. It can only consist of the following types and information (ARONVariant means any Type):
ARON data objects and ARON data DTOs are similar structured to type objects and type DTOs. However, there are fewer classes for data objects and data DTOs. ARON data is completely decoupled from the static types and contains the data members (e.g. an aron data list only contains the list members (as ARONVariants) and not the accepted type):
nullptr
! The reason is that if the type supports maybe types and a member is, for example, optional, the data must support maybetype as well. If a generated ARON class (We come to the code generation later) has an optional member, this member will be translated into a NULL ARON object and DTO.ARON data contains fewer classes than ARON type. Because ARON data objects and DTOs do not check the type of the members (they can be any aron data (ARONVariant)), we can only validate an aron data object or DTO if we have the type information. The following mapping describes, how data and types correspond.
ARON Type | ARON Data |
---|---|
Object | Dict |
Dict | Dict |
List | List |
Pair | List |
Tuple | List |
NDArray | NDArray |
Matrix | NDArray |
Quaternion | NDArray |
Position | NDArray |
Orientation | NDArray |
Pose | NDArray |
Image | NDArray |
PointCloud | NDArray |
IntEnum | Int |
Int | Int |
Long | Long |
Float | Float |
Double | Double |
String | String |
Bool | Bool |
Time | Long |
If no type object or DTO is available, we can at least derive some information from the data object (e.g. "it is a data dict, so the type cant be list").
To differ between data and type makes it easier to work with these Variants. In most cases, the type information is not relevant. Then you only have to check for the data type.
As already mentioned, we implemented wrapper classes around the DTO. These classes offer convenience methods and conversions and make lots things easier when working directly with ARON. These classes can be found at aron/core/{data,type}/variant/Variant.h
.
The ARON objects have more or less the same structure as the DTOs (see above). Everything is stored as a std::shared_ptr
(e.g. members, elements, acceptedTypes, ...). If you want to implement a method which takes any ARON data object as input, you can use the base class of every ARON data object:
If you want to check, what a variant really is, you can use the descriptor of the object:
If you have a DTO, you do not know the exact type, but you want to have a ARON object you can make use of the static construction methods:
If you know the type, you can use the constructor the specific ARON object.
Goal: Have an ARON dict with a list as member "the_list" and some values in it. Then echo the members and their descriptor as a string.
Please note that we might add more methods or make the current ones more flexible (e.g. such as nlohmann::json).