Issue 15013: OCL 2.1 Overload resolution (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: 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. 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.] Resolution: Revised Text: Actions taken: January 30, 2010: received issue Discussion: End of Annotations:===== ronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP4IZEtUXebq/2dsb2JhbADZIII3gg4E Date: Sat, 30 Jan 2010 18:29:29 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.1 Overload resolution X-Plusnet-Relay: 02e76bdae72d9a46695bf73089ff46d3 Hi 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. 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.] Regards From: "Wartik, Steven P \"Steve\"" To: "'ocl2-rtf@omg.org'" Date: Wed, 8 Dec 2010 11:13:33 -0500 Subject: Can equality operator be overridden? Thread-Topic: Can equality operator be overridden? Thread-Index: AcuW8tvpaD9XorEnQlS41a/oYYoxmw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Hi, Does OCL allow the .=. operator to be overridden? I observe that the standard library overrides the operator, but a quick search of the OCL 2.2 specification reveals no general provision. If a class defines operation =(OclAny):Boolean (as do OclVoid and OclInvalid), is equality redefined for that class? Regards, Steve Wartik swartik@ida.org X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQIAIpG/0xUXeb6/2dsb2JhbACCCqBpa3iyRo4DhUkE Date: Wed, 08 Dec 2010 16:50:47 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 To: "Wartik, Steven P \"Steve\"" CC: "'ocl2-rtf@omg.org'" Subject: Re: Can equality operator be overridden? Hi Steve This is issue 15013 amongst others. Overloading is totally unspecified in OCL at present. In discussions with various people, it appears to be sensible to specify a Java-like policy of a) discover the most derived unique signature match statically and store that in the AST b) dynamically dispatch on self with respect to that exact signature at run-time This will form the basis of a future resolution. Nicolas Rouquette found a couple of violations of exact signature overload too late for UML 2.4. The OCL standard library specification has many incorrect overloaded signatures, that should be corrected in OCL 2.4. In particular Collection::=(Collection) is a non-overloading signature. cf Java's Collection.equals(Object). If a Class defines =(OclAny) then there is no doubt that that should be an overload. Whether if Complete OCL defines a body for OclAny::=(OclAny), then that refines = semantics is to be decided. The OCL Standard Library defines OclAny::=(OclAny) using a postcondition contract that uses OclAny::=(OclAny) so provision of a body to accompany a postcondition could be compatible. Perhaps OCL needs some mechanism to bound the redefinitions that may be installed when evaluating OMG Specification constraints, or is a user allowed to 'complete' the standard library arbitrarily provided all constraints in the OCL and UML and ... specifications remain satisfied? [Incidentally Issue14918 identifies a failure to redine OclAny::=(OclAny) for values, so no OCL implementation that works intuitively for values is actually comopliant!] Regards Ed Willink On 08/12/2010 16:13, Wartik, Steven P "Steve" wrote: Hi, Does OCL allow the .=. operator to be overridden? I observe that the standard library overrides the operator, but a quick search of the OCL 2.2 specification reveals no general provision. If a class defines operation =(OclAny):Boolean (as do OclVoid and OclInvalid), is equality redefined for that class? Regards, Steve Wartik swartik@ida.org -------------------------------------------------------------------------------- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1170 / Virus Database: 426/3303 - Release Date: 12/07/10 Ed Willink