Issue 15009: OCL 2.1 11.2.3  Navigated Implicit Conversion to Collection Literal (ocl2-rtf)
Source: Nomos Software (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: 
Revised Text: 
Actions taken:
January 29, 2010: received 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