Hi Adolfo, Christian
Christian: we'd appreciate your thoughts/recollections on this.
Treating Ecore-Invariant EOperations as OCL operations was what I tried
first. Unfortunately EMap<EJavaObject, EJavaObject> cannot be
expressed in any OCL 2.x; I meant to add a comment to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=192907, but that won't
happen for quite some time; even deciding between <T>, (T), [T]
or {T} could be hard. (The definitions of Collection, Tuple and
product() in the new Reflective library branch use something
approaching arbitrary generics.)
My next idea (https://bugs.eclipse.org/bugs/show_bug.cgi?id=191689#c43)
was to deprecate Ecore-Invariant EOperations OCL-wise, but that was not
met with enthusiasm, though I am still waiting to hear a reason why we
need them. 'depecate' is not much of a deprecation for a facility that
was not previously available.
I was hoping that a review of the of the old tutorials on OCL with
Ecore might shed some light on why Ecore-Invariants exist and what we
might do to make them work again.
So, at present, the OCLInEcore editor presents an Ecore-Invariant
EOperation as a Class invariant but remembers that it came from an
EOperation and so updates it accordingly. I would be delighted to
remove this complexity.
Perhaps Christian can help us with the history.
Regards
Ed Willink
On 05/03/2010 10:48, Adolfo Sánchez-Barbudo Herrera wrote:
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2721 - Release Date: 03/03/10 19:34:00
|
