DDS-XTypes 1.3 RTF Avatar
  1. OMG Issue

DDSXTY13 — Inheritance rules not sufficient regarding keys and memberID assignment

  • Key: DDSXTY13-23
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    XTYPES should specify that if a type declares key members then derived types cannot add additional key members.

    The reason is that the derived type will never be compatible with the base type according to the compatibility rules so there is no purpose on allowing that inheritance which would mislead the user.

    Semantically it seems that extending the key breaks the substitution principle where a derived class can be used in place of a base-class anywhere. If we allowed key extension two different objects could appear to be the same when viewed as a "base class"

    Additionally in section 7.3.1.2.1.1 'Member IDs' there is no mention of how inheritance impacts the automatic assignment of member IDs.

  • Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 13:02 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Specify rules for inheritance

    The rules for inheritance could be added to a subsection following *7.2.2.4.4 'Aggregated Types'*. This new subsection should state that:

    Structure types can inherit from other structure types as long as:

    • The derived structure either has same extensibility kind or leaves the extensibility kind unspecified
    • The derived type does not have a member with the same name or the same memberId as the base type or any of the ancestor types (i.e. recursively applying this rule to the parent)
    • The derived type does define any key fields. Is this really what we want to do. Will it break some definition where the "base type" is just being reused as a "header"? All to think about it and come up with a preferred approach.

    Also mention in 7.3.1.2.1.1 'Member IDs' that the memberId are continuing from the base class.

  • Updated: Tue, 8 Oct 2019 17:55 GMT