Issue 15009: OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: The Issue 14981 considered use of explicit null as a Collection. 11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'. Surely when the null arises as a navigation result, the isOrdered and isUnique characteristics of the navigated property should determine what CollectionKind the null result is converted to? However meta-modelling tools and meta-modellers pay little attention to the isUnique and isOrdered characteristics of zero and unit multiplicity properties. Using this overlooked information may cause surprises. Resolution: 7.6.3 Navigation over Associations with Multiplicity Zero or One suggests non-collection are converted to Sets. Similarly 7.6.5, 9.7. So there is a contradiction in the normative conversion to Set or Bag. Set seems more sensible and what the non-normative clauses suggest. Using the accidental ordered/unique attributes of non-collections would lead to horrible surprises for existing usage, so it must be conversion to a set. Since the conversion of null yields an empty set, whereas any other object yields a single element set, the Set size is data dependent and so must be determined at run-time and cannot be expressed as a CollectionLiteralExp. Rather, evaluation of PropertyCallExp and OperationCallExp must detect a mismatch between a non-collection source type and a collection-type referredOperation class. Delayed resolution is inconsistent with OCL's static typing, so let us make it explicit by defining OclAny::oclAsSet() for the static analysis to invoke and perform the conversion. The conversion is represented as a regular OperationCallExp in the AST and only type-dependent run-time decisions need to be made. Note that the revisions below do not address the deficiencies in the normative Clause 9 text raised by Issue 15790. We continue to rely on the final sentence of 9.7: "The mapping is not formally defined in this document but should be obvious." Revised Text: see pages 49 - 50 of ptc/2013-09-01 Actions taken: January 29, 2010: received issue December 23, 2013: closed issue Discussion: End of Annotations:===== ronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgFAHMbYkvUnw4T/2dsb2JhbACBbZhNwEOEQAQ Date: Fri, 29 Jan 2010 07:21:32 +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 11.2.3 Navigated Implicit Conversion to Collection Literal X-Plusnet-Relay: e1c31f112659663a8836a978dfda0f90 Hi The Issue 14981 considered use of explicit null as a Collection. 11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'. Surely when the null arises as a navigation result, the isOrdered and isUnique characteristics of the navigated property should determine what CollectionKind the null result is converted to? However meta-modelling tools and meta-modellers pay little attention to the isUnique and isOrdered characteristics of zero and unit multiplicity properties. Using this overlooked information may cause surprises. Regards Ed Willink On 20/01/2010 16:12, Juergen Boldt wrote: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKKyUkvUnw4R/2dsb2JhbADTWIQyBA Date: Sun, 17 Jan 2010 14:51:57 +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 Implicit Conversion to Collection Literal X-Plusnet-Relay: 781505890f3ebb33b32e1d51eca2e87b Hi The specification is very vague as to how and when a non-collection is converted to a collection. 11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'. 7.5.3 states that 'Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.' The collection type inconsistency between Bag{} and Set{x} makes compile-time type resolution difficult, since the null-ness of x cannot be known till run-time. It would be better to have either Set or Bag uniformly as the conversion collection type. Bag{} as the least useful seems more appropriate. When a conversion is applicable is unclear. In the example, self.manager->isEmpty() is intended to be interpreted as if self.manager.isUndefined() then Set{} else Set{self.manager} endif->isEmpty() so that null->isEmpty is also valid. However is null->excludesAll(null) equivalent to Bag{}->excludesAll(Bag{}) and so true? A simple policy of 'wherever a collection is required and a non-collection is provided perform an implicit conversion to collection-literal' resolves this. However are null = Bag{} or Bag{} = null both equivalent to Bag{} = Bag{} and so true? In this case we have a problem of asymmetric overloading. null = Bag{} satisfies the signature for OclVoid::=(OclAny) and so returns false. Bag{} = null could satisfy the signature for Bag::=(Bag) and so return true with the help of an implicit conversion. Presumably an additional OclVoid::=(Collection) overload is needed to restore symmetry. Regards Ed Willink