| Re: [mdt-ocl.dev] OclInEcore feedback |
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. --
|
