Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 370087

Summary: [oclinecore] Add Conversion Delegate support
Product: [Modeling] OCL Reporter: Ed Willink <ed>
Component: CoreAssignee: OCL Inbox <mdt-ocl-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3    
Version: 3.2.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
Whiteboard:
Bug Depends on: 394658, 378206    
Bug Blocks:    

Description Ed Willink CLA 2012-01-30 01:11:49 EST 
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.
Comment 1 Ed Willink CLA 2012-05-02 02:43:51 EDT 
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.
Comment 2 Ed Willink CLA 2013-07-12 06:01:40 EDT 
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.
Comment 3 Ed Willink CLA 2020-09-30 05:35:34 EDT 
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.
Comment 4 Ed Willink CLA 2020-10-26 03:51:30 EDT 
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.