I
would much prefer to do this, but the discussion at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=191689#c43 and beyond
suggests that both are valid Ecore behaviour. We therefore have the
problem that Ecore capability and terminology is confusing from an OCL
perspective. The wiki needs to be clear, but must not hide the
confusion. I felt that the pedantic usage of "Ecore-Invariant" was
correct. Perhaps it needs a bit more introduction.
I insist on my suggestion. I don't want to prohibit the usage of the
"old style" (the Ecore-invariant), I'm only suggesting that an
OCLinEcore Editor shouldn't consider this special case of "EClassifier
Invariant", but as any other "EOperation body". So for every
EOperation( EDiagnosticChain and EMap<EjavaObject, EJavaObject>)
: EBoolean:
- EMF would treat it as an "Ecore-Invariant" when generating, while
OclInEcore would treat it as an EOperation body.
- OclInEcore would manage it, in an easier way. You don't have any
ambiguity when producing the Ecore annotations from the text.
- The documentation would be coherent (or not confusing) from a pure
OCL perspective. I don't find any need to explain some
derived-from-implementation concepts, if it's not really necessary.
As you say in https://bugs.eclipse.org/bugs/show_bug.cgi?id=191689#c45
"If both really are differently useful, it would be nice to know what
the difference is and I'll try to make the OCLinEcore editor loss-less
and the OCLinEcore wiki reflect this difference."
>From my point of view, I don't find a useful difference. Therefore, we
should not struggle the editor logic to distinct the way OCL consider
EClassifier invariants from the way EMF does.
Cheers,
Adolfo.
I've
just raised bug 304642 to revise the documentation. It would be really
good if one person read all the documentation so that we can gain some
consistency. It would be great if you can do this; as a non-native
English speaker you are more critical of clumsy verbosity. Please do
simple changes, and raise separate bugzillas for more substantive
efforts that you do not have time for; a list of three URLs with
conflicting descriptions at least helps the next guy.
Regards
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|