Home » Modeling » OCL » EObject methods will not be available after Helios M4 milestone.
|
| Re: EObject methods will not be available after Helios M4 milestone. [message #503568 is a reply to message #503364] |
Mon, 14 December 2009 17:43   |
Eclipse User |
|
|
|
Originally posted by: dvorak.radek.gmail.com
Hi Ed,
I would like to discourage from adding reflection to OclAny.
What kind of container(), contents(), get() do we have for
example for primitive types?
The QVT spec adopts the MOF Element concept, at least there has been
an attempt ;), so it defines a subset of its reflection capabilities
+ some additions.
As an extension to OCL, QVT would now receive a duplicate functionality via
OclAny.
If OCL 2.1 needs to address reflection and an issue has to be submitted,
why
not to unify on something reasonable for all possible languages built
on the top of OCL?
To my observations, if IMPLICIT_ROOT_CLASS is explicitly set in
Environments (as EObject) by OCL clients, they sort of get what they had
in the past.
Regards,
/Radek
On Sat, 12 Dec 2009 12:58:17 +0100, Ed Willink <ed@willink.me.uk> wrote:
> Hi
>
> An accidental feature of EMF up until 2.6M4 was that EModelElement
> extended EObject, with the result that EObject methods such as
> eContainer(), eContents(), eGet() could be used in OCL expressions on
> models that extended EModelElement. If as recommended by a number of
> newsgroup postings, the IMPLICIT_ROOT_CLASS option was set to EObject,
> the EObject methods could be used for any models.
>
> EMF is discontinuing this inheritance in 2.6M4
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=255469). This breaks
> backward compatibility, but eliminates an unwanted incompatibility with
> the OCL specification. EObject methods will not be available without
> some new approach.
>
> My current favoured approach is to support e.g.
>
> self.oclAsType(ecore::EObject).eContainer()
>
> so that the only deviation from the specification is a built-in
> visibility of ecore::EObject and the successful cast to a Class not in
> the meta-model.
>
> Now that OCL 2.1 has made it clear that MOF reflection is not supported
> for models, I am considering submitting an OMG issue that adds the
> reflective methods:
>
> OclAny::oclContainer()
> OclAny::oclContents()
> OclAny::oclGet()
> OclAny::oclSet()
>
> etc. These methods could be compatible with other non-Ecore OCL
> implementations.
>
> Comments on the above proposals are welcome.
>
> Regards
>
> Ed Willink
>
>
>
|
|
|
| Re: EObject methods will not be available after Helios M4 milestone. [message #504642 is a reply to message #503568] |
Mon, 21 December 2009 21:05 |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Radek
My ideas have progressed a little, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=283052#c6 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=259031#c12
For MDT/OCL there are an embarrassing number of bugs related to the (lack of a) run-time type system and the second-class status of
oclstdlib as a model. I would like to address these by creating an extensible modelled run-time type system, so that the oclstdlib
model defines behaviour rather than a large number local if inaccurate clauses. Conformance to OclAny will then be defined by a
particular oclstdlib meta-model instance rather than MDT/OCL Java code. QVTo should then be able to provide an alternate or extended
oclstdlib meta-model instance.
For OMG OCL, there is a major problem that the type system of the library is never explicitly defined.
In particular the incompatibility of the Standard Library's concept of 'conformsTo' and the UML concept of generalisation was
identified first by Christian Damus in http://www.omg.org/issues/ocl2-rtf#Issue12795 and in greater depth by me in a not yet visible
submission.
The problem is that OCL at run-time is not the same as UML and pretending that it is has led to this problem. It is the missing
oclstdlib meta-model that defines the 'conformsTo' relationship allowing YourClass to conformTo OclAny even though OclAny is not a
general of YourClass. Similarly it is the oclstdlib meta-model that provides feature polymorphism between a meta-model (e.g.
YourCollection::size(), a constraint (context YourCollection def: size() Integer ...) or a built-in (Collection::size()). And it
will be the oclstdlib meta-model specification that removes the UML specification variation point on whether method overriding
occurs or not.
If the standard library is defined using an OCL run-time library meta-model, a very attractive number of problems appear to vanish.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=259031#c12 indicates my intention to work on this a a ReflectiveLIbrary branch to see
how it works out. I am hoping that UML and Ecore bindings will be an irrelevant choice from the OCL programmers point of view; the
parameterisation of OCLExpressionCS<C> might be obsolete. The UML and Ecore bindings choice will affect only toolsmiths who through
Environment<?,?,?,?,?,?,?,?,?,?,?,?> can select the meta-model representation they prefer.
This is happening in a branch
a) to find out what is possible
b) then to establish a maximum/acceptable compatibility between the old and new code
The ReflectiveLibrary branch is my private work area, feel free to examine it, but do not expect it always to be coherent; it is not
a release. Do not attempt to build against it. Some APIs will be broken to assess their impact, and most will probably be restored
as part of the acceptable compatibility phase.
I am acutely aware that there is limited time before M6, so something radically different needs to be highly compatible.
Implementing IMPLICIT_ROOT_CLASS as you suggest may well be a necessary compatibility.
Regards
Ed Willink
radek dvorak wrote:
> Hi Ed,
>
> I would like to discourage from adding reflection to OclAny.
> What kind of container(), contents(), get() do we have for
> example for primitive types?
>
> The QVT spec adopts the MOF Element concept, at least there has been
> an attempt ;), so it defines a subset of its reflection capabilities
> + some additions.
> As an extension to OCL, QVT would now receive a duplicate functionality via
> OclAny.
>
> If OCL 2.1 needs to address reflection and an issue has to be submitted,
> why
> not to unify on something reasonable for all possible languages built
> on the top of OCL?
>
> To my observations, if IMPLICIT_ROOT_CLASS is explicitly set in
> Environments (as EObject) by OCL clients, they sort of get what they had
> in the past.
>
> Regards,
> /Radek
>
>
> On Sat, 12 Dec 2009 12:58:17 +0100, Ed Willink <ed@willink.me.uk> wrote:
>
>> Hi
>>
>> An accidental feature of EMF up until 2.6M4 was that EModelElement
>> extended EObject, with the result that EObject methods such as
>> eContainer(), eContents(), eGet() could be used in OCL expressions on
>> models that extended EModelElement. If as recommended by a number of
>> newsgroup postings, the IMPLICIT_ROOT_CLASS option was set to EObject,
>> the EObject methods could be used for any models.
>>
>> EMF is discontinuing this inheritance in 2.6M4
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=255469). This breaks
>> backward compatibility, but eliminates an unwanted incompatibility
>> with the OCL specification. EObject methods will not be available
>> without some new approach.
>>
>> My current favoured approach is to support e.g.
>>
>> self.oclAsType(ecore::EObject).eContainer()
>>
>> so that the only deviation from the specification is a built-in
>> visibility of ecore::EObject and the successful cast to a Class not in
>> the meta-model.
>>
>> Now that OCL 2.1 has made it clear that MOF reflection is not
>> supported for models, I am considering submitting an OMG issue that
>> adds the reflective methods:
>>
>> OclAny::oclContainer()
>> OclAny::oclContents()
>> OclAny::oclGet()
>> OclAny::oclSet()
>>
>> etc. These methods could be compatible with other non-Ecore OCL
>> implementations.
>>
>> Comments on the above proposals are welcome.
>>
>> Regards
>>
>> Ed Willink
>>
>>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 11:55:07 GMT 2024
Powered by FUDForum. Page generated in 0.03005 seconds |
] 
Search
Help
Register
Login
Home
