Community
Participate
Working Groups
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.]
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.
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.
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.
Created attachment 206483 [details] Patch to reprioritise get Missing patch from previous comment.
