DDS-XTypes 1.0 FTF Avatar
  1. OMG Issue

DDSXTY_ — Difficult to apply automation to statically defined types

  • Key: DDSXTY_-9
  • Legacy Issue Number: 16241
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Application code (i.e. business logic) generally depends statically on particular types and their members. Therefore, it is appropriate to define these types statically (e.g. in IDL) and generate code for them in order to take advantage of static type safety and improved performance.

    In contrast, infrastructure code (i.e. logic that is independent of particular applications) generally must not depend on application-specific types, because such dependencies prevent that code from being reused.

    These two kinds of code can exist within a single component. For example:

    · The properties of application-specific types might be checked against a common set of rules to ensure that they meet organizational or program-specific guidelines.

    · Certain design patterns may call for arbitrary application-specific types to be augmented in uniform ways.

    · Type-specific application activities, such as reading and/or writing data, might be logged or recorded.

    The straightforward way to handle these scenarios would be to:

    1. Convert a generated type definition into a DynamicType object.

    2. Convert an object of a generated type into a DynamicData object.

    3. Pass these two dynamic objects to the infrastructure code and allow it to operate on them.

    Unfortunately, the specification does not provide such a capability. Instead, applications have to manually construct DynamicType and DynamicData objects member by member. This code is not only verbose but also brittle, because if the static type definition changes (e.g. during development or across versions), it can grow out of sync with the hand-written code that manipulates that definition.

    Discussion:

    We need three new conversions:

    1. TypeSupport à DynamicType

    2. DynamicData à sample object

    3. Sample object à DynamicData

    These operations could either be added to the TypeSupport interface or to a “type builder” interface. The former approach is preferred, because the generic type parameter of the TypeSupport in the C++ and Java PSMs allows a degree of type safety that way.

    Proposed Resolution:

    Introduce three new TypeSupport operations:

    1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.

    2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object. If the DynamicType of the DynamicData is not compatible with the TypeSupport’s data type, raise an error.

    3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Introduce three new TypeSupport operations:
    1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.
    2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object.
    3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.

  • Updated: Fri, 6 Mar 2015 21:48 GMT