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

Bug 358570

Summary:

Add support for a 'get' EAnnotation body

Product:

[Modeling] EMF

Reporter:

Ed Willink <ed>

Component:

Core

Assignee:

Ed Merks <Ed.Merks>

Status:

NEW ---

QA Contact:

Severity:

enhancement

Priority:

Version:

2.7.0

Target Milestone:

---

Hardware:

OS:

Windows Vista

Whiteboard:

Bug Depends on:

362960

Bug Blocks:

279638

Attachments:

Description	Flags
Support for 'get' EAnnotation bodies	none
Patch to reprioritise get	none

Description Ed Willink

2011-09-22 08:42:23 EDT

A 'body' EAnnotation detail on an EOperation supports provision of the Java code body of that operation. This can be exploited by MDT/OCL to support direct Java generation of OCL Invocation and Validation delegates.

It would helpful to allow a similar EAnnotation detail on an EStructuralFeature to support provision of the body of a getXxxx() or basicGetXXXX().

[This is probably useful for Xcore toom for which a 'setBody' detail might also be helpful.]

Comment 1 Ed Willink

2011-10-03 15:13:40 EDT

Created attachment 204469 [details]
Support for 'get' EAnnotation bodies

Attached supports a 'body', 'isset', 'set' and 'unset' EAnnotation details for an EStructuralFeature anologuous to the 'body' detail for an EOperation.

OCL only needs 'body' and a 'return true' for 'isset'. It seems as easy to provide all the inserts as not, using the 'body' as a master to switch off unnecessary setting delegates.

This enables OCL to Java conversion of InvocationDelegates and SettingDelegates. After reification of 'EConstraints' as EOperations, ValidationDelegates can also be supported for EClasses.

Unfortunately there's a problem for ValidationDelegates for EDataTypes since the 'EConstraints' cannot be converted to EDataType operations. The easiest fix is to promote EClass.eOperations to EClassifier.eOperations eliminating the prohibition on EDataType helper functions. While this is notionally compatible, it is presumably unacceptable, so it may be necessary to copy a load of JavaJet from Class.javajet to ValidatorClass.javajet.

Comment 2 Ed Willink

2011-11-03 18:14:30 EDT

Reviewing the latest N-build, a fix for this has been committed.

Just get, rather than get/isSet/unset/set; no problem, I only needed get.

get detail is called "get" rather than "body"; no problem, I can change.

The positioning of the if (genFeature.hasBody()) has moved from first to last. This means that hasBody has lower priority than hasSettingDelegate() which is inconsistent with invocation delegates for which a body annotation overrides the invocation delegate. Please promote the hasBody test above hasSettingDelegate.

Comment 3 Ed Willink

2011-11-04 16:03:52 EDT

The following revised patch against the latest CVS (the auto-generated Class.java is omitted).

a) re-instates the suppression of the EINVOCATION_DELEGATE made redundant by the presence of an operation body detail

b) re-instates a feature get detail with a higher priority than a setting delegate, suppressing the corresponding ESETTING_DELEGATE.

The earlier patch had an explicit isSet detail. The default now applies, so the derived value is gotten and compared to its default. eSet ans eUnset seem to drop-through to do nothing.

basicGet now also uses the get detail; I suspect that this is correct.

Comment 4 Ed Willink

2011-11-04 16:05:05 EDT

Created attachment 206483 [details]
Patch to reprioritise get

Missing patch from previous comment.