Community
Participate
Working Groups
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.
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.
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.
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.
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.
