OCL 2.1 RTF Avatar
  1. OMG Issue

OCL21 — Exact type of Set{} and missing Set(MyType){} literal definitions

  • Key: OCL21-347
  • Legacy Issue Number: 12953
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    It is not clear what is the concrete type of Set{}. Is it Set(Object), Set(Void)
    Also it seems there is no way to explicitly define an empty collection with a given
    type for the elements.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Discussion of this issue suggested a number of options:
    Option 1: The type of Set{} is Set(OclVoid)
    This does not work because
    is an error since "1" or indeed anything other than null or invalid does not
    conform to OclVoid.
    Option 2: The type of Set{} is Set(OclAny)
    This does not work because
    acc : Set(Integer) = Set{}->including(1)
    is an error since Set(OclAny) is not compatible with Set(Integer).
    Option 3: The type of Set{} is a new built-in type EmptySet(ET) where ET is
    determined in some way.
    This does not work because given the RHS of
    acc : Set(Integer) = Set{}>including(1.0)
    it is difficult to see how ET could be determined more precisely than OclAny
    causing the same problem as Option 2.
    Option 4: The type of Set{} is Set(null)
    Since Set{} and Set(null) have no precise OCL 2.1 semantics there is some
    discretion in defining them, but eventually a dynamic type validation is needed for
    acc : Set(String) = Set(null)


    . The impact on evaluation could be
    mitigated by synthesis of an oclAsType() in the Abstract Syntax Tree, but it is not
    possible to provide a static type for the CollectionLiteralExp. This option could
    work but requires revision of abstract syntax and evaluation specifications.
    Option 5: The type of Set{} is back-propagated
    For instance in
    acc : Set(Real) = Set{}>including(1)>including(-1)
    the type of Set{} is Set(Real) since that is the eventual result type. This involves
    unusual reverse semantics.
    Option 6: The type of Set{} is Set(T) with T chosen for well-formedness of the
    expression in which the Set{} is used.
    For instance in
    acc : Set(Real) = Set{}>including(1)>including(-1)
    the type of Set{} is initially Set(T) where T <= OclVoid. Propagation of the type to
    Set(T)::including(UnlimitedNatural) requires T <= UnlimitedNatural. Propagation
    to Set(T)::including(Integer) requires T <= Integer. Finally, propagation to the
    initializer requires Real <= T. Therefore any Real <= T <= Integer is well-formed.
    The lower bound, Set(Real), is preferred since it avoids many type conversions.
    It is also the same result as Option 5.
    Option 6 involves only additional forward static semantics, has no impact on
    evaluation, no impact on parsing, and gives the intuitively correct OCL 2.1

    In order to impose a user-specified element type and so get static type checking
    of user intent, a collection element type can be specified as:
    acc : Set(Integer) = Set(Integer){}
    It is difficult to parse this in OCL 2.1 because Set is not a reserved word and so
    lookahead is required to determine whether Set(someName) is the start of a
    StringLiteralExpCS or an OperationCallExpCS, with someName perhaps being a
    complicated nested type/value ambiguity.
    Issue 14357 introduces the concept of a restricted word preventing the
    unqualified use of Set as an operation name. The extension is then

  • Updated: Fri, 6 Mar 2015 20:58 GMT