[oclinecore] Add Conversion Delegate support

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 370087 | | Status | NEW | | Importance | P3 enhancement | | Reported | Jan 30, 2012 01:11 EDT | | Modified | Sep 21, 2023 03:06 EDT | | Version | 3.2.0 | | Depends on | 394658, 378206 | | Reporter | Ed Willink |

Description

Conversion Delegates probably would benefit from declaration syntaxes for the EDataType toString/fromString methods.

The method bodies probably need type constructors to populate the EDataType. Or does the EDataType just become another Type in the pivot eliminating EClass/EDataType distinctions?

Conversion Delegates probably cannot be realized in legacy code since there is no type constructor support.

[eclipse-ocl-bot]

By Ed Willink on May 02, 2012 02:43

Standard OCL functionality should support

MyType{'my-value'} to construct a MyType from its string representation (Bug 378205 raised).

myType.toString() to create its string representation.

The conversion delegates presumably support the realisation of the above facilities by OCL function bodies.

Looking at the various conversion functions for Ecore, particularly EDate, which reuse a hidden Java type, it is not clear how OCL can sensibly contribute this functionality without an ability to make any Java access (operation or field) callable from OCL.

Tooling such as Modisco that supports model creation from Java code could enable OCL to access Java as a model. Bug 378206 raised.

Once such Java access is available an OCLinEcore enhancement to support the corresponding Java code in EDataType EAnnotations may be useful.

[eclipse-ocl-bot]

By Ed Willink on Jul 12, 2013 06:01

A more specific example occurs for

datatype ENumber : 'java.lang.Number' { serializable };

and subsequent construction as

ENumber{'1'}

which fails in the default EFactoryImpl.createFromString because Number has no String constructor.

In this case we need a datatype constructor that creates an argument-content dependent for use as the requested datatype instance.

[eclipse-ocl-bot]

By Ed Willink on Sep 30, 2020 05:35

On the EMF newsgroup message https://www.eclipse.org/forums/index.php/mv/msg/1105392/1832965/#msg_1832965 Ed Merks commented:

At the end of this section:

https://wiki.eclipse.org/Xcore#Specifying_a_Data_Type

it shows how the create/convert bodies can be specified for an EDataType.

Xcore, in org.eclipse.emf.ecore.xcore.util.XcoreEcoreBuilder.getEDataType(XDataType), uses org.eclipse.emf.ecore.EDataType.Internal.setConversionDelegate(ConversionDelegate) and then org.eclipse.emf.ecore.util.EcoreUtil.getConversionDelegateFactory(EDataType) can find the logic for dynamically interpreting the XBase bodies so that this works for dynamic models.

Of course this assumes the data type's class is actually available in the running IDE.

[eclipse-ocl-bot]

By Ed Willink on Oct 26, 2020 03:51

https://stackoverflow.com/questions/64524369/how-to-validate-java-util-date-attribute-in-ocl invites the availability of EDate methods such as

invariant validation1:\ self.startDate.before(self.terminationDate);

or

invariant validation2:\ self.startDate < self.terminationDate;

Perhaps, the opaque EMF EDataType should be able to see the underlying Java API.