eclipse-ocl-bot
commented
13 hours ago By Christian Damus on Apr 23, 2007 17:17
Updated the EcoreEvaluationEnvironment and UMLEvaluationEnvironment to coerce the results of operation calls and property navigation to the appropriate collection type (if a collection is warranted).
Note that the evaluation of OCL-defined operations and properties is unaffected, as they do not use the metamodel-specific reflection to obtain these values.
Added and/or updated JUnit tests to cover operation calls and property navigation for Ecore and for UML.
| --- | --- | | Bugzilla Link | 183667 | | Status | CLOSED FIXED | | Importance | P2 normal | | Reported | Apr 23, 2007 16:42 EDT | | Modified | May 27, 2011 02:41 EDT | | Version | 1.1.0 | | Reporter | Christian Damus |
Description
The parsed AST of an OCL expression correctly interprets (it seems) the types of multi-valued operations and properties as OCL CollectionTypes of the appropriate kind.
However, in evaluation of an expression, the values of such operations and properties do not always conform. In particular, they are often the original EList returned by eGet() or reflective invocation of Java methods. Moreover, in the former case, manipulation of the resultant list actually modifies the model!
The values returned by OCL should always be copies of the original collection and be of the correct collection type: Set, LinkedHashSet, Bag, or List.