OCL 2.5 RTF Avatar
  1. OMG Issue

OCL25 — OCL 2.1 Overload resolution

  • Key: OCL25-52
  • Legacy Issue Number: 15013
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 6555 introduced the 'missing' Collection::=(Collection(T)) and Collection::=(Collection(T)).

    Issue 12948 changed Collection to conform to OclAny

    This means that "Set{} = 1" is no longer self-evidently invalid.

    According to the inherited OclAny::=(OclAny), "Set{} = 1" should be semantically legal and evaluate to false.

    But if Collection::=(Collection(T)) fully occludes OclAny::=(OclAny) ,"Set{} = 1" should be a semantic analysis failure and so invalid.

    Conversely "1 = Set{}" is OclAny::=(OclAny) and unambiguously false (until a Real::=(Real) overload is introduced to accommodate value rather object identity).

    OCL does not specify any policy for static or dynamic resolution of overloads.

    A Java-like policy of static determination of the most derived valid signature, then dynamic dispatch on the self object would seem appropriate, but:

    let c1 : OclAny = Set

    {1}, c2 : OclAny = Set{1}

    in c1 = c2

    must select OclAny::=(OclAny) as the static signature. Collection::=(Collection(T)) is not a derived operation with the same signature, so evaluation should use OclAny::=(OclAny) rather than Collection::=(Collection(T)) and give erroneous results swhen the collections are compared by object identity rather than collection kind and content.

    OCL must specify multi-dimensional dynamic overload resolution on source and arguments

    OCL should specify Java-like single-dimension dynamic overload resolution and the signature of derived operations such as Collection::=(Collection(T)) should be changed to match their inherited signature, i.e. to Collection::=(OclAny).

    All derived functionality must be folded into the base (OclAny) operation.]

  • Reported: OCL 2.1 — Sat, 30 Jan 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT