search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[pivot] Rationalize numeric *ValueImpl as just *Value #2289

Open eclipse-ocl-bot opened 6 days ago

eclipse-ocl-bot commented 6 days ago

| --- | --- | | Bugzilla Link | 581882 | | Status | NEW | | Importance | P3 normal | | Reported | May 01, 2023 09:13 EDT | | Modified | May 02, 2023 11:18 EDT | | Blocks | 509309 | | Reporter | Ed Willink |

Description

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.

eclipse-ocl-bot commented 6 days ago

By Ed Willink on May 01, 2023 09:19

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.

eclipse-ocl-bot commented 6 days ago

By Ed Willink on May 02, 2023 11:18

(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.