OCL25 — OCL 2.1 Overload resolution

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

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.

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

Or:
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).

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