Issue 14981: OCL 2.1 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 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.

Resolution: Resolved by Issue 15009, where the explicit synthesis of oclAsSet() avoids the troublesome conversions above.
Disposition: See issue 15009 for disposition
Revised Text: 
Actions taken:
January 17, 2010: received issue
December 23, 2013: closed issue
Discussion: 

End of Annotations:=====
ronPort-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