Community
Participate
Working Groups
The Value classes currently emulate EMF with Value interfaces and ValueImpl implementations. It washoped that Values.genmodel would generate them consistently, but it has never worked. The numeric ValueImpl classes extend the non-interface java.lang.Number and so their corresponding Value interfaces fail to assign to Number without a cast. Simplify so that there are just numeric *Value classes that inherit from java.lang.NUmber; interfaces such as Unlimited just for mis-ins.
The current implementation relies on declaring Integer as java.lang.Number in Pivot.ecore for Java gen Integer as org.eclipse.ocl.pivot.values.IntegerValue in OCLstdlib for validation. Using org.eclipse.ocl.pivot.values.IntegerValue consistently requires bogus casts.
(In reply to Ed Willink from comment #1) > Using org.eclipse.ocl.pivot.values.IntegerValue consistently requires bogus > casts. This problem should go awy with no *Impl so we can live with it for now. A few surprises cause limited but nont quite trvial inconvenience. Changing Import.xmiidVersion to IntegerValue hits requires internal int-based code to change and inelegantly costs memory albeit pretty trivial overall. Perhaps a ShortInteger class should allow small integers. Much more significantly all the code based on CollectionType lower/upper has to be revised, but beneficially. Once both API and metamodel use Value all the conversion to use int/long vanish and the confusing between "*", -1, UNLIMITED, UNLIMITED_VALUE can vanish. There are many Boolean[1]-valued properties and operation returns that really do not want to convert from "boolean" to "@Nullable Boolean", so we definitely want an EBoolean as well as Boolean. Conversion to EBoolean can be automated during the synthesis of Pivot.ecore from Pivot.oclas since there is a clear [1]/[?] multiplicity.
