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

Bug 347611

Summary: Add delegate for EDataType, so you can create from and convert to String using a scripting language
Product: [Modeling] EMF Reporter: Hallvard Traetteberg <hal>
Component: CoreAssignee: Ed Merks <Ed.Merks>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: ed
Version: unspecifiedFlags: Ed.Merks: iplog+
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
An experimental implementation.
none
Patch for EDataType delegate implementation none

Description Hallvard Traetteberg CLA 2011-05-30 05:10:45 EDT 
EMF has support for delegates that lets you write invariants, constraints, derived features and operation bodies in a scripting language like Javascript or OCL. However, there's a piece missing that prevents using delegates for implementing all the behavior: that of creating values of an EDataType from a String and converting back. So, I propose adding such a delegate type:
- an annotation key for the EPackage containing the EDataType
- a delegate interface with create and convert methods
- a factory (sub)interface
This delegate must be supported by EFactory, so it is supported for all models (generated or dynamic) and there needs to be new methods in EcoreUtil.

I've attached an experimental implementation that is supported by js4emf. It contains the delegate interface with factory interface, an EcoreUtil-like class with extra methods and an EFactory subclass that works with the new delegate. There's also two classes used by js4emf for testing it, just to show how an implementation might work. The implementation is not fully integrated with EMF (will need to patch, rather than add classes), but it should work as a proof of concept.
Comment 1 Ed Willink CLA 2011-05-30 11:24:30 EDT 
No attachment!
Comment 2 Hallvard Traetteberg CLA 2011-05-30 11:26:34 EDT 
Created attachment 196911 [details]
An experimental implementation.
Comment 3 Ed Willink CLA 2011-05-31 14:06:46 EDT 
The attachment is a ZIP not a patch, so no EMF code is changed and no plugin extensions occur so how can anything change?
Comment 4 Hallvard Traetteberg CLA 2011-05-31 14:42:09 EDT 
(In reply to comment #3)
> The attachment is a ZIP not a patch, so no EMF code is changed and no plugin
> extensions occur so how can anything change?

As I wrote initially, I haven't created a patch, but an implementation that can be used "on top of" EMF. If you register an EDataTypeDelegate.Factory implementation and use the provided EFactorySupporting... for your EPackage, it will use your delegate. The code should illustrate the design and be possible to review before creating a real patch (a bit more work).

In a proper integration, the code in EFactorySupporting... should be moved to EFactoryImpl, the code in EcoreUtilSupporting... should be moved to EcoreUtil, the rest put in the appropriate package and the extension point with code for populating the registry for the delegate must be written.

I can do all this, but first I thought I'd gather comments in the design.
Comment 5 Ed Merks CLA 2011-06-17 11:03:28 EDT 
It's doesn't help that the zip isn't an exported project...

It definitely looks like generally the right approach (modeled after the other types of delegates).  

I'd be a bit concerned about overhead for delegate testing affecting performance of cases where it's not being exploited.  I suspect that could be mitigated by exploiting the fact that the factory knows its package and all the data types passed in should be from that package so that a cheaper guard could be implemented.  In fact, we should probably be defining some type of Internal interface for EDataType so that this stuff can be very efficiently cached.

I'm definitely interested in pursuing this for the coming release cycle.
Comment 6 Hallvard Traetteberg CLA 2011-06-29 09:02:24 EDT 
Created attachment 198824 [details]
Patch for EDataType delegate implementation

Here's a patch for the implementation against org.eclipse.emf.core checked out using the psf specified in http://wiki.eclipse.org/EMF/Getting_Source#Using_Team_Project_Set_File_.28.psf.29

In addition to the core implementation, I've added the extension point, schema and extension point reader and updated plugin.properties. This part has been based on the EOperation Invocation delegate implementation, and I hope no references to it remain. 

I've tested the implementation using a delegate for JS4EMF.
Comment 7 Ed Merks CLA 2011-08-13 00:01:39 EDT 
Note that to implement support for data type conversion in Xcore, I've taken your patch and made a bunch of changes.  See https://bugs.eclipse.org/bugs/show_bug.cgi?id=354245
Comment 8 Ed Merks CLA 2011-10-25 09:12:56 EDT 
Derivative changes have been committed to CVS for 2.8.
Comment 9 Ed Merks CLA 2011-11-22 05:26:29 EST 
The changes are available in builds.