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 <ed@willink.me.uk>
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 <ed@willink.me.uk>
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