DDS-RPC 1.0 FTF Avatar
  1. OMG Issue

DDSRPC_ — Why do we need @Choice

  • Key: DDSRPC_-21
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    We still doubt the need to introduce @choice, with a union with the hash as discriminator value the is always one value active and there is a quick lookup at runtime. It works for the basic profile so why introduce this new IDL behavior for the enhanced one?

  • Reported: DDS-RPC 1.0b1 — Wed, 4 Nov 2015 23:58 GMT
  • Disposition: Resolved — DDS-RPC 1.0
  • Disposition Summary:

    Clarification provided as the rationale

    The following clarification has been provided as the rationale behind @Choice

    It is our intent to support interface inheritance (including multiple inheritance) as cleanly as possible using the tools provided by DDS-Xtypes in the enhanced service profile. @Choice is added in response to that.
    The following must be satisfied.
    1. A requester must be able invoke operations in a service implementing an "evolved" version of the same interface (with more operations or fewer exceptions, etc.)
    2. A base interface requester must be able to invoke operations in a service implementing a derived interface.
    3. In case of multiple inheritance, order of base interfaces should have no impact with respect to interoperability of the derived interface. I.e., interface is a set of operations and has no ordering between.
    Mapping to union requires selection of a discriminator, which has natural ordering. The language mapping rules have to have complex rules to ensure that implicit ordering does not come in the way of supporting interface evolution. For instance, the order in which the base interfaces are listed must be deterministic to get the same union discriminators to all operations. Similarly, the order exceptions must also be deterministic for the operation-specific *_Result structures. (see 7.5.1.2.3 and 7.5.1.2.5)
    The @choice annotation which implies all members are optional and the type is mutable has simple assignability semantics. I believe it has "strong assignability". It really simplifies analysis of interface interoperability and evolvability.
    A common argument in favor of union is its ability to jump to the right member with a single lookup. That's conceptually true but I'm not sure if the mapping of @choice is slow. It requires finding a non-null pointer in an array of pointers. It appears like a micro-optimization.

  • Updated: Tue, 12 Jul 2016 14:44 GMT