Community
Participate
Working Groups
Created attachment 109081 [details] TestCase reproducing this bug OCL does not allow a third party plug-in to provide additional operations when their name collide with existing operations even if their signature does not correspond. As an example, we cannot provide a "last()" EOperation on the primitive type String since a "last()" operation already exists as a predefined operation on OrderedSet(T). In such a case, the "callOperation" method of the EvaluationEnvironment will not be called since an operationCode will be associated to the OperationCallExp by the default EvaluationVisitor. The attached JUnit 3 TestCase reproduces this use case.
Oo! Thanks, especially, for the JUnit test case. That is most helpful.
Committed a fix to the 1.2.2 release. This bug also revealed a latent problem int the AbstractEnvironment implementation of getAdditionOperations(C) and getAdditionAttributes(C), in which they would return null instead of an empty list as required by the contract. Thanks again for the test case; I included it mostly as is. I had to change the assertion because the UnsupportedOperation wouldn't work; the OCL evaluation catches and handles RuntimeExceptions.
Thanks, works wonders with the svn version :)
Fix available in R1_2_maintenance: 1.2.2.M200808290729.
Fix available in HEAD: 1.3.0.I200808302022.
Closing after over a year in verified state.
