QVT 1.3 RTF Avatar
  1. OMG Issue

QVT13 — QVTo: Standard Library return types

  • Key: QVT13-53
  • Legacy Issue Number: 19760
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The objectsOf...(T) family of operations (e.g. Element::subobjectsOfKind(T), or Element::allSubobjectsOfType(T), or Model::objectsOfType(T)) returns a set of Elements.

    It should be possible to infer the precise return type from the given T, i.e., return a Set(T) instead of Set(Element).

    BTW, why is there no Model::objectsOfKind(T) ?

  • Reported: QVT 1.2 — Tue, 19 May 2015 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Define return type for objectsOf...(T) operations more precisely

    The objectsOf...(T) family of operations (e.g. Element::subobjectsOfKind(T), or Element::allSubobjectsOfType(T), or Model::objectsOfType(T)) returns a set of Elements.

    It should be possible to infer the precise return type from the given T, i.e., return a Set(T) instead of Set(Element).

    BTW, why is there no Model::objectsOfKind(T) ?

    Discussion

    We can make the declaraions using the same approximation to a rigorous declaration as used by selectByKind in OCL 2.4.

    Omission of objectsOfKInd is an easily corrected oversight.

    The incorrect objectsOfKind usage by the current objectsOfType is a confusing error that gets worse when the correct operation is provided. Better to correct it.

    clone and deepClone from QVT13-12 can similarly exploit a T.

    The confusing wording of Model::createEmptyModel can be clarified,

  • Updated: Tue, 29 Mar 2016 15:09 GMT