Details

    • Type: Change Request
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: ADL 1.4
    • Fix Version/s: ADL 2.1
    • Component/s: ADL, AOM
    • Labels:
      None
    • Change Description:
      Hide
      There are two ways to see this. The orthodox oo modelling approach is to say: if your model defines X (concrete) as a subtype of Y (also concrete) then at runtime, an X is always acceptable in a variable of type Y. By this argument, archetypes should not try to circumvent this. If on the other hand, there are circumstances where a Y is ok but not an X, then the underlying reference model should say so by modelling X and Y as disjoint subtypes of a common parent W.

      A pragmatic approach would be to do what you say. We could probably argue for this just on the basis of the fact that many reference models (i.e. object models) are not well constructed, and out of the control of the archetype designers, and/or that models consdered good today are shown up later on by changing requirements, which changes the validity of inheritances such as the one Kerry points out.

      This change assumes that the second case is common enough to need support in ADL, and adds a new attribute to C_OBJECT called something like "subtypes_allowed".
      Show
      There are two ways to see this. The orthodox oo modelling approach is to say: if your model defines X (concrete) as a subtype of Y (also concrete) then at runtime, an X is always acceptable in a variable of type Y. By this argument, archetypes should not try to circumvent this. If on the other hand, there are circumstances where a Y is ok but not an X, then the underlying reference model should say so by modelling X and Y as disjoint subtypes of a common parent W. A pragmatic approach would be to do what you say. We could probably argue for this just on the basis of the fact that many reference models (i.e. object models) are not well constructed, and out of the control of the archetype designers, and/or that models consdered good today are shown up later on by changing requirements, which changes the validity of inheritances such as the one Kerry points out. This change assumes that the second case is common enough to need support in ADL, and adds a new attribute to C_OBJECT called something like "subtypes_allowed".

      Description

      From Kerry Raymond @ DSTC:
      Looking at the archetype models, there appears to be no way to enforce that the class to be used for some specific piece of information is exactly that class and not one of its subtypes. For example, what if it is important to have a DVTime used and not a DVPartialTime? Or an ObjectRef that should never an AccessGroupRef or a PartyRef?

      My feeling is that the class constraint in an archetype needs an additional property "subtypesAllowed" or similar to cater for the two cases.

        Attachments

          Activity

            People

            • Assignee:
              thomas.beale Thomas Beale
              Reporter:
              thomas.beale Thomas Beale
              Analyst:
              Thomas Beale
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: