Community
Participate
Working Groups
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.
No attachment!
Created attachment 196911 [details] An experimental implementation.
The attachment is a ZIP not a patch, so no EMF code is changed and no plugin extensions occur so how can anything change?
(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.
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.
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.
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
Derivative changes have been committed to CVS for 2.8.
The changes are available in builds.
