Open eclipse-ocl-bot opened 1 month ago
By Ed Willink on Mar 17, 2020 10:12
Oops. This is breaking wrt one QVTc JUnit test that has a persisted xmi:id for a changed LUSSID. Options:
a) revamp the LUSSIDs to have selective semantic blindness where there is no overload opportunity.
b) introduce aka's so that a new OCLstdlib has multiple old xmi:ids
c) tough, OCLstdlib is work-in-progress
d) have genuinely distinct OCLstdlib versions for each evolution
At present, and in particular with the new work on invalidity analysis, the OCLstydlib declarations are subject to a succession of subtle evolutions.
Freezing the LUSSIDs is not feasible. So will have to be c) tough for a while.
By Ed Willink on Mar 17, 2020 10:57
On further invesrigation, the specific QVTC test failure was on CollectionIncludesOperation for which:
operation includes(object : OclAny[?]) : Boolean[1]
changed to
operation includes(object : T) : Boolean[1]
It seems two sets of changes get bundled. T rather than OclAny is in accord with OCL 2.4 which also has T for excludes.
(In contrast Java has remove(Object) allowing lazy remove without casting, but pace the new JDT "unlikely argument" warning, no diagnosis of a stupid type. The stronger OCL declaration seems better. The weak Java type may be a legacy of the old pre-generic Collection-of-Object.)
However this is still a subtle OCLstdlib evolution.
| --- | --- | | Bugzilla Link | 561117 | | Status | NEW | | Importance | P3 normal | | Reported | Mar 14, 2020 06:17 EDT | | Modified | Mar 17, 2020 10:57 EDT | | Reporter | Ed Willink |
Description
Many declarations such as
force a may-be-null on T and V inhibiting any inference of cannot-be-null.
The unnecessary [?] should be removed.